System, Apparatus for Content Delivery for Internet Traffic and Methods Thereof

ABSTRACT

In one embodiment, a method of serving media includes receiving user profiles from a layer3 node in an access network, and receiving a request to serve media content to a user equipment. The user profiles include information relating to user account and/or network characteristics of the user equipment. The method further includes using an user equipment information from the user profiles, assigning a first media server from a hierarchical set of media servers to serve the user equipment if the media content to be served is cacheable. The hierarchical set of media servers include a plurality of first type of media servers deployed in a plurality of layer2 (L2) access networks. The user equipment is coupled to a content delivery network through a layer2 access network of the plurality of layer2 access networks.

This application is a divisional application of U.S. patent applicationSer. No. 13/105,666 which claims the benefit of U.S. ProvisionalApplication No. 61/334,548, filed on May 13, 2010, now U.S. Pat. No.9,386,116 to issue Jul. 5, 2016, which application is herebyincorporated by reference.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application relates to the following co-pending and commonlyassigned patent application: Attorney Docket No. HW 82910748.1U.S. Ser.No. 13/105,439, filed May 11, 2011, which application is herebyincorporated herein by reference.

TECHNICAL FIELD

The present invention relates generally to content delivery, and moreparticularly to system, apparatus for content delivery for internettraffic and methods thereof.

BACKGROUND

In recent years, media consumption using mobile devices has dramaticallyincreased. Consequently, telecommunication networks are bursting at theseams because of this explosive growth in traffic. This phenomenon iseven more evident in the Mobile Broad Band (MBB) networks where the costof infrastructure is much more (e.g., about 20-30 times) than that ofthe Fixed Broad Band (FBB) networks. The recent proliferation of mobiledevices, such as smart-phones, tablets, netbooks, laptops, has kickedoff a new era of wireless access to full web on the go. Consequently,the growth of multimedia traffic is expected to be much faster than thegrowth of traffic in FBB networks in its first 5 years of growth (e.g.,from year 2000 to year 2005).

However, MBB and FBB network operators do not benefit from thisincreased traffic. Most of this fast growing traffic does not contributeto the revenue for the MBB and FBB network operators because thistraffic is classified to be direct to consumer traffic, which is oftenreferred to as Over-The-Top (OTT) traffic. Therefore, mitigating theimpact of the rapidly growing OTT traffic becomes an urgent priority forthe MBB and the FBB network operators.

OTT traffic differs from other traffic such as Business-To-Business(B2B) or Business-To-Consumer (B2C) traffic in that the OTT content andtraffic characteristics are unknown to the operators. These unknowncharacteristics include media origin, media type, deliveryprotocol/schemes used, protected vs. clear content, dynamic vs. staticcontent, etc. Therefore, handling and mitigating the impact of OTTtraffic is difficult because of the technical complexity, network costs,and uncertain nature of the OTT handling.

SUMMARY OF THE INVENTION

These and other problems are generally solved or circumvented, andtechnical advantages are generally achieved, by illustrative embodimentsof the present invention.

In accordance with an embodiment of the present invention, a method ofmedia streaming comprises receiving user profiles from a layer3 node inan access network, and receiving a request to serve media content to auser equipment. The user profiles include information relating to useraccount and/or network characteristics of the user equipment. The methodfurther comprises using an user equipment information from the userprofiles, assigning a first media server from a hierarchical set ofmedia servers to serve the user equipment if the media content to beserved is cacheable. The hierarchical set of media servers comprise aplurality of first type of media servers deployed in a plurality oflayer2 (L2) access networks. The user equipment is coupled to a contentdelivery network through a layer2 access network of the plurality oflayer2 access networks.

In accordance with another embodiment of the present invention, a methodof serving media comprises receiving user profiles from a mediacontroller in a content delivery network. The user profiles includeinformation relating to user account and/or network characteristics ofan user equipment. A request to serve a cacheable media content to theuser equipment is received. The user equipment is coupled to the contentdelivery network through a access network. Using an user equipmentinformation from the user profiles, a quality of experience for the userequipment is determined. The method further comprises serving thecacheable media content to the user equipment at the quality ofexperience for the user equipment.

The foregoing has outlined rather broadly the features of an embodimentof the present invention in order that the detailed description of theinvention that follows may be better understood. Additional features andadvantages of embodiments of the invention will be describedhereinafter, which form the subject of the claims of the invention. Itshould be appreciated by those skilled in the art that the conceptionand specific embodiments disclosed may be readily utilized as a basisfor modifying or designing other structures or processes for carryingout the same purposes of the present invention. It should also berealized by those skilled in the art that such equivalent constructionsdo not depart from the spirit and scope of the invention as set forth inthe appended claims.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present invention, and theadvantages thereof, reference is now made to the following descriptionstaken in conjunction with the accompanying drawing, in which:

FIG. 1 illustrates a prior art access network offload solution using aGi Offload method for handling OTT traffic;

FIG. 2 describes a prior art method (“Traffic Offload Function (TOF)based Gi offload”), which is also referred to as Mobile Edge AccessGateway (MEAG) in accordance with TR 23.829 standard as Alternative 4;

FIG. 3 describes a prior art method (“Local Gateway GPRS Support Node(GGSN) method”) used in MBB networks in accordance with current 3GPPstandards;

FIG. 4 illustrates a unified content delivery network solution for MBBand/or FBB networks in accordance with an embodiment of the invention;

FIG. 5, which includes FIGS. 5A-5D, illustrates the configuration of theL2 network in accordance with embodiments of the invention;

FIG. 6, which includes FIGS. 6A-6D, illustrates the configuration of theL3 network and content delivery network in accordance with embodimentsof the invention;

FIG. 7 illustrates a unified content delivery solution as applied to aMBB network in accordance with an embodiment of the invention;

FIG. 8, which includes FIGS. 8A-8D, illustrates different configurationsfor configuring components in a content delivery network in accordancewith embodiments of the invention;

FIG. 9 illustrates a hierarchy of media servers deployed in accordancewith embodiments of the invention;

FIG. 10 illustrates a table of packet data protocol (PDP) context datastored in a media controller in accordance with an embodiment of theinvention;

FIG. 11 illustrates control and media message flow operations for normalhandling in accordance with an embodiment of the invention;

FIG. 12 illustrates possible reassignment of resources when a UErelocates/roams within/across multiple networks in accordance withvarious embodiments of the invention;

FIG. 13 illustrates a table corresponding to reassignment of resourceswhen a UE relocates/roams within/across multiple networks and highlightsthe possible impact in accordance with embodiments of the invention;

FIGS. 14A and 14B illustrate the general network architecture forhandling of relocation and roaming in a MBB network in accordance withembodiments of the invention, wherein FIG. 14A illustrates an embodimentof roaming under scenario II in FIG. 12, and wherein FIG. 14Billustrates an embodiment of roaming under scenario III in FIG. 13;

FIG. 15 illustrates a modified procedure for UE relocation across SGSNsin accordance with an embodiment of the invention;

FIG. 16 is a prior art reference configuration of packet switched lawfulinterception (LI) under 3GPP 33.107, which is incorporated herein byreference;

FIG. 17 describes a embodiment for a method of implementing lawfulinterception;

FIG. 18, which includes FIGS. 18A and 18B, describes an alternativeembodiment for a method of lawful interception wherein the media serverin the layer2 network decides and delivers communications with atargeted UE, wherein FIG. 18A illustrates a context diagram ofimplementing LI and FIG. 18B illustrates the LI message flow;

FIG. 19, which includes FIGS. 19A and 19B, describes a third embodimentfor a method of lawful interception wherein the media server in thelayer2 network decides and delivers communications with a targeted UEbut through the media controller, wherein FIG. 19A illustrates a contextdiagram of implementing LI and FIG. 19B illustrates the LI message flow;

FIG. 20 illustrates the general network architecture for handling ofcharging, reports, and analytics as well as quality of experienceprovisions in accordance with embodiments of the invention;

FIG. 21 illustrates the general network architecture for handling offailure of media server(s) in accordance with embodiments of theinvention;

FIG. 22 illustrates a XDSL network implementing embodiments of theinvention described above;

FIG. 23 illustrates a cable broadband network implementing embodimentsof the invention described above;

FIG. 24 illustrates a representative media server in accordance withembodiments of the invention;

FIG. 25 illustrates components of a media controller for serving mediain accordance with embodiments of the invention;

FIG. 26 illustrates components of a media server for serving media inaccordance with embodiments of the invention;

FIG. 27 illustrates components of a content processing unit for servingmedia in accordance with embodiments of the invention;

FIG. 28 illustrates components of an interworking function unit forserving media in accordance with embodiments of the invention;

FIG. 29 illustrates components of a second media server for streamingmedia in accordance with embodiments of the invention;

FIG. 30 illustrates components of a media controller for streaming mediain accordance with embodiments of the invention;

FIG. 31 illustrates components of a layer3 node 3100 for streaming mediain accordance with embodiments of the invention;

FIG. 32 illustrates components of a media server for streaming media inaccordance with embodiments of the invention;

FIG. 33 illustrates components of a deep packet inspection node inaccordance with embodiments of the invention;

FIG. 34 illustrates components of a media server in accordance withembodiments of the invention;

FIG. 35 illustrates components of a media server in accordance withembodiments of the invention;

FIG. 36 illustrates components of a media controller in accordance withembodiments of the invention;

FIG. 37 illustrates components of a media server in accordance withembodiments of the invention;

FIG. 38 illustrates components of a media data function in accordancewith embodiments of the invention;

FIG. 39 illustrates components of a media server at a layer2 accessnetwork in accordance with embodiments of the invention;

FIG. 40 illustrates components of a media controller in accordance withembodiments of the invention;

FIG. 41 illustrates components of an inter working function unit inaccordance with embodiments of the invention; and

FIG. 42 illustrates components of a media controller in accordance withembodiments of the invention.

Corresponding numerals and symbols in the different figures generallyrefer to corresponding parts unless otherwise indicated. The figures aredrawn to clearly illustrate the relevant aspects of the embodiments andare not necessarily drawn to scale.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

The making and using of various embodiments are discussed in detailbelow. It should be appreciated, however, that the present inventionprovides many applicable inventive concepts that can be embodied in awide variety of specific contexts. The specific embodiments discussedare merely illustrative of specific ways to make and use the invention,and do not limit the scope of the invention.

Definition and acronyms of basic functional entities, interfaces betweenthem, used in the following description is described below.

Acronyms:

AAA—Authentication, Authorization, and Accounting

ADMF—Administration Function for lawful interception

B2B—Business to Business (a model where the operator provides servicesto another business)

B2C—Business to Consumer (a model where the operator provides servicesto its end users)

BC—billing and charging policy server

BG—Border Gateway (peering point to the internet)

CC—CDN Control (control function that decides which MS to handle a givenrequest)

CDN—Content Delivery Network (open CDN that supports OTT, B2B, and B2C)

CG—Charging Gateway (responsible for charging aspect of services)

DF—Delivery Function (a LI infrastructure term)

DPI—Deep Packet Inspection (a function that inspects packets)

DPI-C—Content Request Level DPI (involving deep HTTP header, URLanalysis)

DSL—Digital Subscriber Line

FBB—Fixed Broad Band (XDSL, cable networks, etc.)

GGSN—Gateway GPRS Support Node

GPRS—General Packet Radio Services

GSN—GPRS Support Node (either an SGSN or GGSN)

IWF—Inter-Working Function (a special function for connecting L2 nodeand media server)

L2 Node—Layer 2 Node (such as RNC and Node-B in MBB, DSLAM in FBBnetworks etc.)

L3 Node—Layer 3 Node (such as GGSN in MBB or BRAS in FBB etc.)

LEMF—Law Enforcement Monitoring Function

LI—Lawful Interception (provides interface for LI such as MBB's LIG)

LIG—Lawful Interception Gateway

LIMS—LI Management System

MBB—Mobile Broad Band (2.xG, 3G, 4G, or WiMax networks)

MC—Media Control (same as CDN Control Function)

MD—Media Data (Data Analytics, Logs and Reports)

MS—Media Server (provides media streaming, caching, and adaptationfunctions)

MX—Media Switch (same function as MS)

NB—Node-B (a 3GPP RAN function, i.e., Radio Base Station also called BS,eNB)

OCS—Online Charging System

OTT—Over The Top (type of content and traffic that are unknown to thenetwork operator)

PCC—Policy Charging and Control

PCRF—Policy, Charging Rules Function

PS—Policy Server (such as PCRF in MBB)

QoE—Quality of Experience (Quality of End User Experiences)

QoS—Quality of Service

RNC—Radio Network Controller (a RAN control function in the 3GPPstandard)

SGSN—Serving GPRS Support Node

SUR—Subscriber Usage Report

UE—User Entity (end user device/client)

XDSL—All variants of DSL technologies such as ADSL and HDSL.

Different prior art methods of handling OTT traffic will be describedwith respect to FIGS. 1-3. However, the inventors have identified thatthese prior art methods have different advantages and disadvantageswhich are discussed in further detail below.

The application described below uses the abbreviation GGSN and SGSN onlyas an illustration. The terms could also be servers performing theseoperations in the network. For example, the server performing theoperations of GGSN in a 3GPP LTE/4G network is referred as systemarchitecture evolution gateway (SAE-GW) and the server performing theoperations of SGSN in a 3GPP LTE/4G network is referred as MobilityManagement Entity (MME). Therefore, the class of servers performing theoperations of the GGSN, the SAE-GW, and similar equivalent servers maybe referred as gateway server node and the class of servers performingthe operations of the SGSN, the MME, and similar equivalent servers maybe referred as serving/management node. GGSN and SGSN are used in thedescriptions only as an illustration and any corresponding server may beused in various embodiments described herein.

FIG. 1 illustrates a prior art access network offload and cachingsolution using a Gi Offload method for handling OTT traffic.

FIG. 1 illustrates a user equipment (UE 10) coupled to the internet 70through a layer2 (L2) network 20, such as a radio access network, alayer2 (L2) node 21. The L2 node 21 may be a base station, NB, eNB, aradio network controller etc. The L2 network 20 is coupled to theinternet 70 through a layer3 (L3) network 30. The L3 network 30 providesservices such as a charging gateway (CG) 31, a lawful interception (LI)32, and a policy server (PS) 33.

The Gi Offload method is widely used in Mobile Broad Band (MBB)networks. In the Gi Offload method, a caching media server MS 41 isintroduced through the IP traffic network 40. The functionality of theMS 41 may be implemented as a standalone cache function or as a mediaserver as part of a CDN network. The deep packet inspection DPI 37function may be standalone or as a part of the L3 Node 36 (such as agateway GPRS support node (GGSN)). However, the Gi Offload method doesnot help alleviate traffic pressure below the DPI function becausecontent is cached very high up in the network path. To solve thisproblem, a second method has been introduced as illustrated in FIG. 2.

FIG. 2 describes a prior art method (“Traffic Offload Function (TOF)based Gi offload”), which is also referred to as Mobile Edge AccessGateway (MEAG).

In the MEAG method, the offload position is moved from the L3 Node 36(such as Gi at GGSN) to the L2 Node (e.g., RNC). Gi is the IP basedinterface between the GGSN and a public data network (PDN). Asillustrated in FIG. 2, the TOF 22 is introduced into the L2 network 20.Therefore, this method is able to provide bandwidth savings above theTOF 22 (i.e. saving realized in all of the L3 Nodes 36 above the TOF22). However, in order to support all of the other supporting servicesassociated with the MBB access network such as Lawful Interception (LI),real time charging services, and policy based QoS services (PCRF), TOF22 has to support direct interfaces with the CG 31, LI 32, and PS 33functions as illustrated in FIG. 2.

An optional MS function, the MS 41 (dotted line box) may be included asa standalone caching server or a media server as part of a CDN network.The offload function and caching functions are inherently decoupled, butcan be combined to offer additional benefits.

However, this method has many drawbacks. First, all traffic is analyzedat the TOF 22 using Deep Packet Inspection (DPI) type of approach. Thissignificantly degrades performance of the L2 network 20. Second, inorder to support the MBB related services such as CG 31, LI 32, and PS33, direct interfaces from TOF 22 to these functions must be maintained,complicating the interactions for CG 31, LI 32, and PS 33. Third, toachieve the first and the second above, the TOF 22 is likely to become acomplex function having many of the common functions of the MBB's SGSNand GGSN functions.

In spite of these drawbacks, this method has been adopted into TR23.829standard as Alternative 4. This next method attempts to improve on someof these drawbacks in this second method.

FIG. 3 describes a prior art method (“Local Gateway GPRS Support Node(GGSN) method”) used in MBB networks. Under this method, the L2 Node isa Radio Network Controller (RNC), and the L3 Node is a Local GGSN.

This method (again in the MBB domain) attempts to use a standard GSNhandling called direct tunnels, which allows a L2 node 21, such as aRNC, in the L2 network 20 to establish a direct tunnel to a local L3node 26 such as a local GGSN. Therefore, a local GGSN is positionedbeside the RNC (L2 node 21), thereby allowing the RNC to offload certaintypes of traffic (such as web traffic) to the internet via the LocalGGSN (local L3 node 26). Existing SGSN and GGSN function are in thenon-offload path under this method.

Two slightly different configurations have been proposed for thismethod: static offload and dynamic offload. First, in the static offloadconfiguration, once setup, the offload traffic will statically gothrough the local L3 node 26 (Local GGSN) and non-offload traffic willcontinue through L3 Node 36 (GGSN). As shown in FIG. 3, at the time ofthe packet data protocol (PDP) setup, a SGSN (another L2/L3 Node) maydetermine the static configuration. This requires modification to theSGSN for offload policy handling and identification of Local GGSN.

Alternatively, the dynamic offload configuration is shown with thedotted line between the local L3 node 26 and the L3 node 36. In thiscase, all data traffic go through local L3 node 26 (Local GGSN), whichmakes offload decision, including applying different offload policy ondifferent flows within a single PDP. SGSN will always choose a L3 node36 (macro GGSN), and the local L3 node 26 (Local GGSN) serves as theproxy for the macro GGSN.

This method has similar benefit as the second method in terms of savingthe core L3 Nodes (SGSN, GGSN in the MBB context). However, since GGSNis a standard MBB function and its interface with CG 31, LI 32, and PS33, etc. are already defined and standardized, introducing local GGSN atthe L2 node 21 (such as a RNC) appears to solve many of the problems.Unfortunately, there are additional drawbacks of this method as outlinedbelow.

First, a L3 Node 36, such as a GGSN, is a complex function and itsimplementation is relatively expensive and difficult to manage.Therefore, having multiple GGSN nodes is not cost effective. Second,with multiple GGSNs in the network, the interaction between CG 31, LI32, and PS 33 etc. becomes more complicated. For example, the real timecharging function will need to receive inputs from both GGSN (local L3node 26 and L3 node 36) in order to determine if an active session hasreached a rating limit. Third, this scheme may present a challenge in asingle access point name (APN) setup where all services use a singleAPN. In particular, the static offload configuration described above,once the packet data protocol (PDP) is setup, the statically determinedoffload from L2 node 21 (RNC) to the local L3 node 26 (Local GGSN)cannot be changed.

In various embodiments of the present invention, various innovativemethods of deploying layer3 based content delivery network (CDN) MediaServers (MS) into any layer2 access networks (such as RAN networks orXDSL access networks, or even cable networks) will be described. Suchdeployments of the CDN media servers may be used to cache and processmedia content closer to the user devices, while maintaining a unified,common, and open CDN network capable of handling OTT, B2B, and B2Cservices for both MBB and FBB networks.

The cost savings potential for the existing network infrastructure isgreater if the CDN media server is located closer to the end user devicewhen caching the OTT content delivered through an access network (MBB orFBB) to the end user. This is because the infrastructure cost of RadioAccess Network (RAN) nodes is progressively more than those of thePacket Switching (PS) network. Consequently, it is advantageous to movethe media server further down the access path towards end user devices.

However, last mile access network may be a layer2 network or may be anon-IP closed networks such as RAN (in 3G wireless networks) or XDSL.Deployment of a media server in to these networks has at least twochallenges. First, the media server, which is typically a layer 3 node,requires special interfaces to interact with the layer2 network. Second,regular offload (TOF) schemes require a DPI process so as to determineif an OTT flow is cacheable and to offload or cache locally. This DPIprocess may be very CPU intensive and may degrade the capacity of theaccess nodes.

Embodiments of this invention overcome these and other problems bydeploying a layer3 media server into a layer2 access network withfunctionality decoupling. In particular, some functionality, such as OTTtraffic detection, caching decision and the OTT traffic request routingdecision, is retained within the layer3 CDN networks. Embodiments of theinvention also include unique handling for features in the MBB networkdomain such as Lawful Interception (LI), Online Charging System (OCS)related handlings, QoS handling and support, as well as many othercapability supports for both MBB and FBB networks.

Embodiments of the invention will be first described using the systemarchitectural framework of FIG. 4. Detailed structural embodiments ofvarious units will be described using FIGS. 5-6, 8-9. Embodiments of theinvention as applicable to mobile broadband network, XDSL network, cablebroadband network will be described using FIGS. 7, 22, and 23respectively. Embodiments for flow operations for MBB network will bedescribed using FIG. 11. Embodiments of the invention relating tohandling of roaming/relocation will be described using FIG. 12-15.Embodiments of the invention for lawful interception will be describedusing FIG. 17-19. Embodiments of the invention for handling of charging,reports, and analytics as well as quality of experience provisions willbe described with respect to FIG. 20. Embodiments of the invention forhandling of failure of media servers will be described with respect toFIG. 21.

FIG. 4 illustrates a unified content delivery network solution for MBBand/or FBB networks in accordance with an embodiment of the invention.

In FIG. 4, the UE 10 represents an end user device such as a mobile ordevice with a wireless card. Referring to FIG. 4, a L2 network 20 havingmultiple L2 nodes 21 and a L3 network 30 having multiple L3 nodes 36form an access network towards the internet 70. Various embodimentsinclude an inter-working function IWF 23 and a L3 based media serverMS-A 24 within the L2 network 20 beside the L2 node 21. The IWF 23serves as the interface and routing function between the layer2 nodes inthe L2 network 20 and the MS-A 24.

Media servers located in L2 networks are labeled as MS-A, while mediaservers located in L3 networks are labeled as MS-B so as to distinguishthe different type of media servers. Within the L3 network 30, a deeppacket inspection (DPI) 37 function examines UE requests for signaturematch to determine if a request needs to be diverted to the contentdelivery network (CDN) 80 for further processing. Therefore, the DPI 37diverts certain UE requests to the CDN 80 for further processing.

DPI 37 may be configured to inspect the packet passing through it, forexample, searching for protocol non-compliance, viruses, spam,intrusions or predefined criteria to decide what actions to take on thepacket, including collecting statistical information. DPI 37 may add theability to look through Layers 2-7 of the OSI model, which may includesheaders and data protocol structures as well as the actual payload ofthe message. DPI 37 may identify and classify traffic based on asignature database that includes information extracted from the datapart of a packet, allowing finer control than classification based onlyon header information. In one more embodiments, the DPI 37 may identifyif the traffic comprises an OTT class. A classified packet may beredirected, marked/tagged, blocked, rate limited, and/or reported to areporting agent in the network.

The CDN 80 is typically a set of servers strategically deployed over anall IP network and may or may not be hierarchical. The CDN 80 may have aplurality of different units, which may be geographically distributed.Examples of units within the CDN 80 include servers placed at variouspoints in CDN 80. For example, a UE 10 may access a copy of the datathat is in the nearest server, as opposed to accessing from a centralserver. Alternatively, multiple users located at similar locations mayaccess same files from different servers preventing overloading of asingle repository server. Content types stored in CDN 80 may include webobjects, downloadable objects (media files, software, documents),applications, real time media streams, and other components of internetdelivery (DNS, routes, and database queries).

In various embodiments, an off-path content level deep packet inspectionunit (DPI-C) 81 in the content delivery network (CDN) 80 understands theOTT requests and decides the appropriate media server to serve the UEmaking the media request. By using an external DPI-C 81, the impact tothe existing network components is minimized. This is because DPI 37 istypically already integrated into the L3 nodes 36. Therefore, theadditional functionality is separated from the already existing DPI 37.

In various embodiments, the MS-A 24 is introduced into the L2 network20, which is much closer to the UE 10, while decoupling functionality ofthe CDN 80 with the L2 network 20 and the L3 network 30 as much aspossible. In various embodiments, the intensive operations, such asDPI-C 81 functionality, are maintained at the CDN 80, which is betterequipped for performing complex tasks than the L2 nodes 21. This avoidsthe need for adding expensive resources to the L2 nodes for performingintensive operations. Advantageously, by combining the above, the accessnetworks (MBB or FBB) and CDN 80 can maintain their relativeindependence in functionality while cooperating to maximize theeffectiveness of handling OTT traffic, and the B2B and B2C services ifthey are also present in a common unified approach.

The inserted functions in the L2 networks 20 and the L3 networks 30 maytake on several different configuration forms as illustrated in FIGS. 5and 6.

FIG. 5, which includes FIGS. 5A-5D, illustrates the configuration of theL2 network in accordance with embodiments of the invention.

FIG. 5A illustrates an embodiment in which the L2 Node 21, the IWF 23,the MS-A 24 are formed as separate units (e.g., physically separatemachines). In FIG. 5B, the L2 Node 21 and the IWF 23 are a singleintegrated unit (same box/machine) while MS-A 24 is formedindependently. In FIG. 5C, the IWF 23 and the MS-A 24 are formed as anintegral unit while L2 Node 21 is a separate unit. In FIG. 5D, all thecomponents are integrated into a single physical unit.

In FIG. 5, configurations illustrated in FIGS. 5A and 5C offer thebenefit of transparent introduction of MS-A 24 into the L2 network 20without any impact to the L2 Nodes 21. This requires the IWF 23 to offercomplete transparency for L2 nodes 21 when MS-A 24 is introduced into L2network 20. One of the benefits of this is that L2 node 21 may beoffered from a different provider than the provider offering IWF 23 andMS-A 24.

In contrast, the configuration in FIG. 5B allows significantsimplification of the IWF 23 because many of the messaging and data flowinformation for a L2 communication is already present in the L2 node 21.

FIG. 6, which includes FIGS. 6A-6D, illustrates the configuration of theL3 network and content delivery network in accordance with embodimentsof the invention.

FIG. 6A illustrates an embodiment in which the L3 Node 36, the DPI 37,the DPI-C 81 are formed as separate units (e.g., physically separatemachines). In FIG. 6B, the L3 Node 36, the DPI 37 are a singleintegrated unit (same box/machine) while DPI-C 81 is formedindependently. In FIG. 6C, the DPI 37 and the DPI-C 81 are formed as anintegral unit while L3 Node 36 is a separate unit. In FIG. 6D, all thecomponents are integrated into a single physical unit.

Referring to FIG. 6, the configurations of FIGS. 6A and 6B offer thebenefit of minimal delay for the non-OTT traffic, and the decouplingbetween the access network 30 (L3 node 36 and DPI 37) and the CDNnetwork 80 (DPI-C 81). Decoupling the content level DPI and the basicDPI for OTT traffic recognition is advantageous because content levelDPI for handling OTT requires on-going tuning of the DPI signature andprovisioning for the DPI algorithms to handle changes in the OTT contentand traffic profiles.

Therefore, configurations illustrated in FIGS. 6C and 6D are unable tooffer these benefits. Since many L3 nodes 36 currently deployed alsoinclude the ability to perform DPI 37, configuration of FIG. 6B has theadded advantage of reusing the function of the DPI 37 embedded in the L3nodes 36. However, the configurations illustrated in FIGS. 6C and 6D maybe deployed in new architecture scenarios where backward compatibilityand pre-existing equipment issues do not exist.

The associated functions at the top of the L3 network 30 (CG 31, LI 32,and PS 33) serve as the charging, lawful interception and policy serverfunction to complete the access network services. There are severalother innovative features surrounding the interaction with thesefunctions which will be discussed later in the document. For clarity,functions not closely related to the description and understanding ofthis invention has been omitted.

FIG. 7 illustrates a unified content delivery network as applied to aMBB network in accordance with an embodiment of the invention.Embodiments of the invention applied to MBB networks particularly havemany advantages although embodiments of the invention as described withrespect to FIG. 4, which illustrates a generic method and apparatus, areapplicable to both Mobile Broad Band (MBB) and Fixed Broad Band (FBB)networks.

FIG. 7 illustrates MBB functional components mapped onto the genericdescription of FIG. 4. Referring to FIG. 7, in this embodiment, Node-B(NB) 121 and/or RNC 122 may be the L2 nodes 21 of FIG. 4, while GGSN 136may be the L3 node 36 in FIG. 4. As in FIG. 4, a caching media serverMX-A 124 is deployed within a radio access network 120. The dotted linein FIG. 7 is an alternative MX-A 124′ (along with an alternative IWF123′) deployment location (at NB) for the caching media server althoughdeploying the MX-A 124 in the RNC 122 remains to be the deploymentlocation of MX-A for practical purposes. The CDN Control (CC) 82function in FIG. 4 may be a media controller (MC) 182 function in FIG.7. The MC 182 selects and assigns the best positioned media server MX(MX-As and MX-Bs) to serve a given request from UE 110.

The connection between IWF 123 and MX-A 124 is an L2/L3 connection sothat traffic to and from MX-A 124 can be routed properly into and out ofthe L2 network via the IWF 123. Practically, all of the MX-As' 124 IPaddresses may be provisioned to be the same for the RNCs 122 and IWFs123 (as in the case of wireless application protocol gateways WAP GW's),but MX-As 124 have separate uniquely routable IP address towards theCDN/internet side of the network. As described further below, in otherembodiments, alternative IP address allocation using an IP address poolfor MX-As may also be used as described later.

The dotted line between MX-A 124 and CDN 180 represents an all IPtransport network which is likely available in most MBB deployments. Inan alternative embodiment, a tunnel/path through RNC 122/IWF 123-SGSN135-GGSN 136-DPI 137 may be used to communicate with components in theCDN 180. This alternative requires IWF 123 to provide needed routingtranslation between MX-A 124 and CDN 180 from within confines of thetunneling protocols (e.g., GPRS tunneling protocol for carrying userdata GTP-U). Therefore, this is more efficient if the IWF 123 isintegrated with the RNC 122 so that the packaging of GTP message andcontext are in place when routing messages from MX-A 124.

In various embodiments, the communication between GGSN 135 and MC 180may take on at least two forms.

In a first embodiment, as illustrated in FIG. 7, the GGSN 136 and MC 182may have a direct private interface Gmc (a simple RESTful API, i.e., anapplication programming interface conforming to the representationalstate transfer constraints) for GGSN 136 to provide relevant PDP contextinformation to MC 182 for request handling. There are two additionalmodes of operations of this private interface. In various embodiments, adirect interface between the GGSN 136 and the MC 182 is provided, whichmay use other type of protocol for request handling as known to oneskilled in the art.

First, GGSN 136 may push any new creation, update, and deletion ofactive PDP contexts to the MC 182. Each GGSN 136 may only need to pushthe information to the MC 182 it is connected with assuming each GGSNdirectly connects with at most one MC 182.

Second, the MC 182 may always query GGSN 136 for the PDP context infousing the current IP address of the UE 110 as the query key. The MC 182only queries the GGSN(s) 136, with whom the MC 182 is directlyconnected. If multiple GGSNs are connected to a single MC, then thequery may be sent to all of the multiple GGSNs unless the DPI 137includes information of the GGSN 136 in the forwarded requests and MC182 is designed to parse for it.

In a second embodiment, as illustrated in FIG. 7, the UE HTTP messageparameter augmentation may be relied upon to pass on PDP informationfrom GGSN 136 to the MC 182 through the DPI 137, the DPI-C 181. In thiscase, the GGSN 136 includes those relevant PDP context parameters (seeTable 1) in the augmented HTTP header. This option may impactperformance of the GGSN 136 because the augmentation of HTTP messages atGGSN 136 requires additional processing.

FIG. 8, which includes FIGS. 8A-8D, illustrates different configurationsfor configuring components in a content delivery network in accordancewith embodiments of the invention.

In various embodiments, the DPI-C 181, the MC 182, and the MX-B 184 maybe implemented in separate units (e.g., physically different computers)or integrated. FIG. 8A illustrates an embodiment in which the DPI-C 181,the MC 182, and the MX-B 184 are implemented as separate units in theCDN 180 while FIG. 8D illustrates an embodiment in which they areintegrated into a single unit. In FIG. 8B, the DPI-C 181 and the MX-B184 are implemented together in a single unit, while in FIG. 8C theDPI-C 181 and the MC 182 are integrated together.

FIG. 9 illustrates a hierarchy of media servers deployed in accordancewith embodiments of the invention. Embodiments of the invention includea hierarchical set of media servers including a first media server MX-A124 in the radio access network 120, a second media server MX-B 184 inthe CDN 180, and a third media server MX-C 194 in the higher levels,e.g., at a packet delivery network (PDN) peering point, or a bordergateway. The media controller (MC 182 in FIG. 7) in the CDN 180 selectsthe appropriate media server MX when a UE requests to be served.Therefore, embodiments of the invention create a hierarchical cachingnetwork under CDN control from MBB RAN networks to PDN's peering points.

The hierarchy of media servers provides the CDN 180 the ability tohandle the unique characteristics of MBB networks. For example, hot,warm and colder content (hot being most requested) may be cached atdifferent levels of the cache hierarchy. In one or more embodiments,MX-A, MA-B, and MC may be assigned to keep local, regional, and overallcontent hotness respectively to optimize cache efficiency at variouslevels and balance request handling over the CDN network.

FIG. 10 illustrates a table of packet data protocol (PDP) context datastored in a media controller in accordance with an embodiment of theinvention.

Referring to the table in FIG. 10, the MC 182 may keep a subset of PDPcontext data in a table, for example, indexed by the UE IP address inorder to sync up with PDP status from GGSN 136 for those users handledby MC 182. In the first embodiment and the first mode of operationdiscussed above, the GGSN 136 may only push updates to MC 182 when thereis any change in the PDP context. The MC 182 may maintain its PDPcontext table using current UE's IP address.

The embodiments of FIGS. 4-9, 12, 14, 15, 17-24 may also be described orillustrated in terms of methods comprising functional steps and/ornon-functional acts. The following (and aforementioned) description andrelated flow diagrams illustrate steps and/or acts used in practicingexample embodiments of the present invention. Usually, functional stepsdescribe the invention in terms of results that are accomplished,whereas non-functional acts describe more specific actions for achievinga particular result or step. Although the functional steps and/ornon-functional acts may be described or claimed in a particular order,the present invention is not necessarily limited to any particularordering or combination of steps and/or acts. Further, the use (or nonuse) of “steps for” and/or “acts of” in the recitation of the claims—andin the following description of the flow diagrams(s) for FIG. 11, 18B,19B is used to indicate the desired specific use (or non-use) of suchterms.

FIG. 11 illustrates flow operations for normal handling in accordancewith an embodiment of the invention.

When a UE, such as UE 10 in FIG. 4 or UE 110 in FIG. 7, requests to viewa video from a video portal, such as youtube, hulu, amazon video etc, anHTTP message will be sent to the video portal. This requires that a DNSquery and a corresponding TCP connection be established first between UEand video streaming server.

In various embodiments, a PDP context between the UE and the GGSN isestablished and/or activated (step 201). A PDP context stores the PDPcontext data for the requesting UE including. In one or moreembodiments, the PDP context includes the RAN side MX IP address, e.g.,IP address of the MX-A from the side of the RAN 120 in FIG. 7. The PDPcontext may also include the standard parameters as described in FIG.10.

Next, the UE transmits a HTTP GET REQUEST to the GGSN/DPI through theRNC/IWF (messages 210 and 211). The GGSN/DPI node processes the receivedHTTP GET request. The DPI may look for certain signature of the HTTPrequest such as destination IP address and port#, and compare them witha pre-stored list of the OTT signatures to determine if this request isto fetch a OTT content. For some OTT sites, the signature analysis mayinvolve more than a 5-tuple analysis and real DPI of HTTP headerparameters analysis may be required, which requires a different type ofsignature.

In the flow diagram, it is assumed that this request matches thesignature stored at the DPI (DPI determines that the request is OTTcontent). The DPI forwards this HTTP GET request to DPI-C (deep contentURL DPI) via an IP connection between the DPI and the DPI-C function(message 212). DPI will not change anything on this HTTP GET requestmessage. In some embodiments, this forwarding may be implemented viaGeneric Routing Encapsulation (GRE) tunnel or Web Cache CommunicationProtocol (WCCP).

Next, DPI-C decides whether the content is cacheable content. The DPI-Cfunction receives the forwarded HTTP GET request from the DPI. DPI-Cperforms a deep URL and HTTP header analysis to try to match the storedsignatures at DPI-C function with the forwarded message. The requiredDPI-C signatures and algorithms may vary depending on the specific videoportal sites to be handled (for videos such as Youtube, BBC, Hulu, etc.)and/or software download sites (for large files such as windows updates,etc.). In one or more embodiments, the DPI-C focuses on HTTP messagetype, UserAgent while other parameters may be included in variousembodiments.

In the illustration of FIG. 11, it is assumed for this flow the initialvideo portal media request (as with most other video sites) does notmatch the signature described above (i.e. DPI-C determines the contentis not cacheable). For example, this request may lead to an HTML page onwhich a media player will be initialized and the media player willinitiate a separate request to GET the video file. The DPI-C forwardsthis request unchanged towards the BG (or on-path routers) in the MBBPacket Data Network (PDN) and the HTTP request continues on its journeytowards the Youtube server (message 213).

After several additional HTTP message exchanges, the DPI receivesanother HTTP Get Request from the UE, determines it is OTT content, andforwards it to DPI-C (messages 220, 222, 224). This time, the GETrequest comes from a media player (e.g., a shockwave player). The GETrequest may contain a signature that matches the stored signatures atDPI-C. Therefore, the DPI-C decides that the content is cacheablecontent.

Next, the DPI-C informs the MC regarding its evaluation that the contentis cacheable. In various embodiments, as illustrated in FIG. 8, theDPI-C may run on either MX-B, or MC, or as a stand-alone DPI-C box,depending on the traffic dimensioning profile of the operator. For thisdiscussion, we assume that the DPI-C, MX-B and MC are interconnected androutable at IP level so that the internal connections and forwardingamong DPI-C, MX-B and MC are not detailed here. If the DPI-C runs onMX-B and for those requests that need to be served by the CDN, therequest messages are forwarded from the MX-B/DPI-C to the MC because theMC selects the media server (MX) to serve any given request.

The CDN has to be involved in serving this request after the DPI-Cdetermines that the request is cacheable content and the MC has receivedthe HTTP request from the DPI-C. In one or more embodiments, the MC,which is located in the CDN, performs the following set of MBB networkspecific tasks for selecting the appropriate caching media server (MX)for serving this HTTP request.

As discussed above, the MC stores a subset of the PDP information itgets via Gmc (a RESTful control info API to GGSN, see FIG. 7). Invarious embodiments, the MC may use different alternate methods todetermine which MX-A is in the PDP path serving the current UE.

In one embodiment, location information such as router area identity orservice area identity (RAI/SAI) may be used to select the media server.For example, a RNC is selected based on the RAI/SAI, for example, usinga table that has a mapping between RNC and RAI/SAI. The location of themedia server is decided from the RNC. The MC may store a MC tablecomprising all RNC-RAI/SAI mapping.

In an alternative embodiment, UE IP range and mapping to RNC may be usedif there is such a deterministic relationship. In a further alternativeembodiment, RAN Side MX-A IP Address, which is an optional parameter tobe added in the PDP context at GGSN is forwarded to MC during initialPDP setup or any subsequent changes of parameters. In a furtheralternative embodiment, RNC IP address or ID is obtained viacommunication between GGSN and SGSN, and MC keeps a mapping tablebetween RNC IP/ID and its local MX-A IP.

The MC selects a media server from a hierarchical set of media serversas described in FIG. 9. The method for this selection will be furtherdescribed below. As part of the CDN MX cloud, the MX's keep status andheart beat with the MC's (in the MC cloud) so that the loading conditionand availability of the MXs is instantly known at the MC.

In one embodiments, the MC may decide to redirect the current request toone of the many MX-As (RAN side MX-A's, as UE relocates/roams acrossRNC's. In an alternative embodiment, the MC selects one of several MX-Bat the GGSN level, or one of MX-C's at the one of the packet datanetwork (PDN) peering points or BGs level (as illustrated in FIGS. 7 and9).

In various embodiments, the policy and/or heuristics for determining thebest serving MX can be done in several ways.

In one embodiment, the MC may have a policy of always rounding to thecurrent serving MX-A for a given UE (i.e. IWF/MX-A on the UE's PDPpath), unless the MX-A is overloaded. As the UE travels across RNC'sRAIs/SAIs, the serving MX-A may change depending on scenarios of therelocation. This is further discussed below under roaming/relocation.Under this policy, the MC always picks the current serving MX-A. This isfurther discussed under handling of policies.

In an alternative embodiment, the operator's may have many CDN requestserving policies (as part of the B2B and B2C services under traditionalCDN implementation). Likewise, they can introduce OTT specific requestrouting policies via the same scheme. These schemes may take the form ofeither a set of policies provisioned (statically or dynamically) to theMC's via CDN's Network Operation's Center (NOC) or via configurationtables downloaded to the MX's, or both. When there is a cache miss at aserving MX-A, the local configuration table may be configured to go upthe cache hierarchy to try to obtain the requested content or to consultthe MC for advice as one of the entry in the configuration table.

In various embodiments, after selecting the MX for serving the UE, theHTTP GET request is redirected to the serving MX-A for this UE (messages226, 228, 230, 240, 242). In one or more embodiments, the redirection toMX-A is performed as described below.

The MC or DPI-C constructs and sends a redirect message to the UE. TheMC or DPI-C constructs an HTTP 302 (or HTTP 303 redirect) message withdestination IP as UE, and source IP as video portal server IP address(i.e., destination of current HTTP get request that is being processed).The URL will be augmented with the original service URL which is usefulfor MX-A to retrieve content in cache miss scenarios. Since the MC/DPI-Cand the GGSN/DPI has existing TCP connection, the MC can simply forwardthis fake HTTP 302 message to GGSN/DPI (as message 226) which willnaturally route the request to the destination UE under that UE'sexisting TCP connection with the media portal server (message 228 and230). This assumes that the TCP sequence # matches with the media portalside by analyzing it at the DPI function.

If the above redirection is not possible or not easily done, in analternative embodiment, the TCP connection between the UE and mediaportal server is broken (forcibly disconnected) and a TCP proxy is setup at DPI-C with two separate of TCP connections. A first connection isset up between UE and DPI-C via GGSN/DPI and a second connection is setup between DPI-C and the media portal server via B G.

Using above method, the UE receives a HTTP 302 (or 303) redirectionmessage from the DPI-C/MC. The UE will attempt to contact the new URI/IPaddress which points to the serving MX (MX-A) connected to the RNC andIWF. The UE transmits a HTTP GET to the RNC/IWF (message 240).

The RNC/IWF receives the UE HTTP GET and forwards it to the media serverMX-A. In various embodiments, this may be performed using one of thefollowing embodiments.

In one or more embodiments, if an IWF is embedded inside the RNC, thenthe IWF function will attempt to open GTP-U messages' user data to lookfor the destination IP address of the UE communication. The message isassumed to be destined for the serving MX-A connected to the RNC/IWF ifthe destination IP address maps to a pre-stored IP table at the RNC/IWF.This pre-stored IP table needs to be provisioned into all of theRNC/IWF's as the MX-As are deployed into the RAN network and the RNC/IWFhas to repackage the GTP-U message into an HTTP/TCP/IP message toforwarding to the MX-A.

Alternatively, in another embodiment, IWF may be a separate box outsideof the RNC on the IuPS interface path. The IWF transparently passesthrough all of the RANAP or GTP-C messages between RNC and SGSN. Incontrast, IWF will intercept the GTP-U messages and open the user datato screen for destination IP addresses. If there is a match with the IPaddress pre-stored in the IP table, then IWF function shall repackagethe message and forward it to MX-A connected to it.

MX-A receives the HTTP GET, which is the UE's HTTP request (asredirected by the MC) (message 242). Now that MX-A has received the UE'sHTTP request (as redirected by the MC), MX-A perform the following HTTPrequest processing in various embodiments.

MX-A generates an index to represent content being served. MX-A parsesthe HTTP request for the URL and other pertinent information to derivean index key for the content. The URL construction for video portalsdoes not follow any standard and changes frequently. In variousembodiments, any common identification scheme may be used as long as itproduces a unique ID for each given content file. For example, URLs maybe different but the content identification portion may still be thesame. Therefore, in various embodiments, the content identificationportion may be extracted and used as an index key for the cached contentfile (hashing may be required). Further adjustments may be required foradaptive HTTP delivery because MX-A sees a large number of small videosegment files.

A unique file name is generated at MX-A. The MX-A derives a uniquecontent/file ID from the URL of the HTTP get request. This unique URLportion will be used to create a unique hash key, which may be used tolocate the content/file in MX-A cache system. This may not be 100%reliable and may change over time because the content of the media isOTT. Therefore, two requests for the same content/file may be mapped todifferent file ID, which may create multiple copies of the samecontent/file. Two requests for different content/files may, in someinstances, be mapped to the same content.

The data is retrieved from the cache and transmitted to the UE if MX-Afinds it in the MX-A cache (messages 244 and 246). If there is a cachehit, then MX-A will attempt to serve this file to the UE according tothe UE request. In various embodiments, CDN media adaption (transcoding,transrating, file format adaptation, etc.), PCRF QoS oriented treatments(QoS guarantees and limiting/capping of bandwidth based on user orrating group, etc.) may be applied. This is further discussed withrespect to handling of policies. After applying media adaption asnecessary the MX-A sends the first HTTP response to the UE with mediadata. This is done via the GTP-U routing capability of the RNC/IWF nodethrough the existing GTP-U tunnel between UE and the GSN, using thecorrect GTP-U sequence # kept at RNC/IWF. IWF function needs to keep thesequence # by itself if IWF function is a standalone node separated fromthe RNC on the IuPS interface, while the combined RNC/IWF function doesnot require duplication of this GTP handling function in order to routethe MX-A to UE messages into the UE's existing GTP tunnel.

In various embodiments, after the session with UE terminates, a log iscomputed and transmitted to CDN for various operations such asaccounting, charging, analysis, etc. Media delivery from the MX-A to UEcontinues until the session ends, after which case, MX-A generatesdelivery log(s). These delivery logs are sent to the Media Data (MD)Cloud of CDN network for processing as described below regardingCharging, Report and Analytics.

However, if the requesting data is not in the cache of MX-A, i.e., thereis a cache miss, MX-A follows its stored policy rule (existing CDN/MXfunction) to try to find the content from the next cache server in thecache hierarchy or the origin server (media portal server, whose URL isin the 303/302 redirect message). GGSN/DPI receives the message 250 fromMX-A. DPI and DPI-C recognizes that routing for this HTTP request(message 250) from MX-A is not a UE request and forwards it to the mediaportal server (message 252). This avoids the possibility for an infiniteloop to MC again. The media portal server sends the data requested,which is received as an HTTP response (message 254) at the GGSN/DPI. TheGGSN/DPI forwards the data through the GTP tunnel to the MX-A (messages256 and 258). MX-A may cache the content in its caching system and servethe data to the UE (message 260).

However, in some embodiments, the MX-A may also contact MC to find outthe location of the content in the CDN network. For this fetch from theupper cache server(s), the MX-A may use the original user HTTP requestURL (embedded in the redirect message from the MC), but over a new TCPconnection to the upper cache server or origin server via the IPtransport network as illustrated in FIG. 7.

Embodiments of the invention have several unique advantages. Usingembodiments of the invention allows effective decoupling of AccessNetwork and CDN network for OTT traffic caching. Embodiments of theinvention enable deployment of layer3 based media server (media cachingand adaptation) in a layer2 network, which is advantageously much closerto the end users without the usual complexity of layer2 DPI and decisionmaking. Embodiments of the invention support a more centralized contentlevel DPI (DPI-C) and decision making in a single CDN, which can serveboth MBB and FBB, thereby avoiding including a DPI-C (content level)inside the access network. Embodiments of the invention may leverage alayered cache network to increase cache hit rate and reduce cache missretrieval time. Embodiments of the invention also provide a hierarchy ofcache (MS) backup among distributed MS servers in case of failure of anyMS server. Embodiments of the invention support OTT, B2B and B2Cservices over MBB and FBB networks with a common, unified CDN withidentical network configurations which greatly simplifies networkdeployment, management, and operations.

FIGS. 12 and 13 illustrate the relocation and roaming scenarios inaccordance with embodiments of the invention.

In particular, the UE may roam across multiple networks during asession. Embodiments of the invention describe methods to enable cachingduring/after roaming. Depending on the movement of the UE, differentscenarios are possible. These are listed in FIG. 13 and illustrated inFIG. 12.

FIG. 12 illustrates possible reassignment of resources when a UE roamswithin/across multiple networks. FIG. 13 illustrates a tablecorresponding to reassignment of resources when a UE roams within/acrossmultiple networks and highlights the possible impact in accordance withembodiments of the invention. In a first scenario I, the UE's relocationmay require a relocation of the serving base station, for example,between adjacent base stations (NB1 1211 and NB2 1212). A secondscenario II involves a relocation that requires a relocation in RNC i.e.from a RNC1 1221 to a RNC2 1222 A third scenario III involves requires arelocation in SGSN from SGSN1 1351 to a SGSN2 1352 without changing theGGSN. In a fourth scenario IV, the serving GGSN is relocated i.e. fromGGSN1 1361 to GGSN2 1362. Finally, some UE relocates may involve achange from a MBB to a FBB network or vice versa (not illustrated).

Referring to FIGS. 12-13, in the first scenario (I), the UE moves from afirst base station (NB1 1211) to another base station (NB2 1212) withinthe same RAN 120. However, NB1 1211 and NB2 1212 are controlled by thesame RNC 1221. Therefore, this relocation is transparent to IWF1 1231and the MX-A1 1241 because MX-A1 1241 and IWF1 1231 are shared throughthe common RNC1 1221 (not shown in FIG. 12, see, e.g., 14A).Consequently, no modification is necessary.

Referring to FIGS. 12-13, in the second scenario, UE moves from a firstRNC (RNC1 1221) to a second RNC (RNC2 1222). This scenario has severalhandling options.

FIGS. 14A and 14B illustrate the general network architecture forhandling of relocation and roaming in a MBB network in accordance withembodiments of the invention, wherein FIG. 14A illustrates an embodimentof roaming under scenario II in FIG. 12, and wherein FIG. 14Billustrates an embodiment of roaming under scenario III in FIG. 13.

In a first embodiment, the session may be broken and MC 182 redirectsthe request to a new MX-A (MX-A2 1242), which is local to RNC2 1222.Therefore, in this embodiment, standard 3GPP procedures are followed forrelocation and the session between MX-A1 1241 and UE 110 may break. TheUE auto-retry scheme (present in most media player) will retry the HTTPGET request through the new RNC2 1222, which forwards the request to theMC 182. The MC 182 redirects the request to the new MX-A2 1242 (local tothe RNC2 1222). The new MX-A2 1242 continues content delivery from thereas described above. However, the media may restart from the beginning asopposed to where the UE was cut off.

In a second embodiment, the old MX-A1 1241 associated with RNC1 1221continues to be used. A modified standard 3GPP procedures is followed,which suppresses the relocation procedure at SGSN 135. Therefore, oldMX-A1 1241 continues to deliver to the UE 110 through old RNC1 1221/IWF11231→IuR→new RNC2 1222→new NB2 1212→UE 110 until the session naturallyends. However, any new request from UE will be redirected to the newMX-A2 1242 serving via new RNC2/IWF2. As mentioned above, the SGSN 135is modified to implement this option such that it recognizes that thereis ongoing delivery session between MX-A1 1241 and UE 110, andtherefore, SGSN 135 does not issue a relocation request. Reconfigurationof RNC1 1221 and RNC2 1221 is required in order for them to forward theUE requests back to the old MX-A1 1241 in the old RAN1 1201 network.

In a third embodiment, the session is broken as in the first embodimentbut due to smart buffer management, the UE 110 receives a smooth videowithout any breaking. As in the first embodiment, a standard 3GPPprocedure is followed breaking the session. A special media playerperforms error concealment so that the user sees a smooth playbackalthough redirection processes are implemented in the background. In oneembodiment, the media player includes a smart buffer management withsufficient buffer size. In various embodiments, the media player alsoincludes the ability to retry a non-responding HTTP request with amodified Byte Range parameter so that the media player at the UE willretry starting from where it left off. Since the UE is now in the newRAN2 1202 under the new RNC2 1222, the retry message will be captured bythe DPI 137/DPI-C 181/MC 182, and the MC 182 redirects the request tothe new MX-A2 1242. The rest of the delivery will continue starting withthe Byte Range request from UE. Thereby, the UE avoids restarting themedia from the beginning of the session.

In a fourth embodiment, the MC 182 is informed of the impendingrelocation and MC 182 and/or MX-A1 1241 perform a mid-stream redirectusing a smart session. Therefore, the MC 182 and/or MX-A1 1241 arenotified of an impending relocation (via SGSN 135 or RNC1 1221). The MC182 and/or MX-A1 1241 perform a mid-stream redirect request to relocatethe UE 110. This communication may be transmitted over the existing IWF11231/RNC1 1221→NB1 121→UE 110 or existing IWF1 1231/RNC1 1221→IuR→RNC21222→NB2 122→UE 110. The UE 110 media player is configured to supportthis mid-stream redirect request. The media player is configured tolaunch a request (with Byte Range starting from the current playbacktime code offset) to new MX-A2 1242 in response to the redirectioninstruction from the MC 182 and/or the MX-A1 1241. In the mean time, theUE is receiving the playback from the media player's buffer and does notexperience any interruption. The delivery from the new MX-A2 1242 startsbefore the player buffer is depleted, thereby offering a smooth playbackexperience to the user.

Referring to FIGS. 12-13, in the third scenario, UE moves from a firstSGSN (SGSN1 1351) to a second SGSN (SGSN2 1352). The handling for thisscenario is similar to the handling of the previous scenario with somedifferences in the standard 3GPP messaging flow. Therefore, in variousembodiments, the third scenario may be implemented by (a) breaking thesession and redirecting to a new MX-A 1241, (b) using the current (old)MX-A 1241 until the session terminates, (c) using a smart sessionmanagement procedure while breaking the session and redirecting to a newMX-A 1242, or (d) using a smart session management procedure incombination with a mid-stream redirecting procedure.

FIG. 15 illustrates a modified procedure for UE relocation across SGSNsin accordance with an embodiment of the invention.

Although described with respect to the third scenario III, the proceduredescribed below may also be implemented in the second embodiment of thesecond scenario II.

The MX-A is only related to the packet data. Therefore, all the othersignaling messages of the MBB network caching relocation procedureremain the same as the relocation procedure of 3GPP. The difference inpacket data forwarding illustrated as dashed lines in the messaging flowdiagram above. During SRNS Relocation procedure, packet data between oldMX-A1 1241 and UE 110 are forwarded by source RNC1 1221 and target RNC21222 through LuR, which is the interface between the RNCs. This isillustrated in FIG. 15 as step 6′ in which the packet data from the oldMX-A 1241 is transmitted to the source RNC1 1221. In step 7′, the packetdata from the source RNC1 1221 is transmitted to the target RNC2 1222through IuR. In step 8′, the packet data from the target RNC2 1222 istransmitted to the UE 110.

The above relocation scenarios (steps 6′, 7′ and 8′ in FIG. 15) may beimplemented in different way in various embodiments.

In a first embodiment, the source RNC1 1221 and target RNC2 1222 aremodified. In particular, the source RNC1 1221 is configured to forwardedpacket data, whose destination is MX-A1 1241 address, to MX-A2 1242 inrelocation state. The new RNC2 is configured to forwarded packet data,whose destination is MX-A1 address, to source RNC1 1221 in relocationstate.

In a second embodiment, the target RNC2 1222 may use IP address of theserving MX-A1 1241 (old one) to route through the VPN/IP transportnetwork that connects all of the RNCs and PS core. In this case, eachMX-A has a unique IP address in order for the routing to work.

Embodiments of the invention for implementing lawful interception willbe described using FIGS. 16-19.

FIG. 16 is a prior art reference configuration of packet switched lawfulinterception (LI) under 3GPP 33.107, which is incorporated herein byreference.

In FIG. 16, the reference configuration is only a logical representationof the entities involved in lawful interception and does not mandateseparate physical entities. This allows for higher levels ofintegration.

A Law Enforcement Monitoring Facility (LEMF) is connected to anAdministration Function ADMF and two Delivery Functions DF2 and DF3 eachhaving mediation functions. There is one Administration Function (ADMF)in the network. The ADMF interfaces with all the LEAs that may requireinterception in the intercepting network. The ADMF keeps the interceptactivities of individual LEAs separate and interfaces to theintercepting network.

Together with the delivery functions, multiple activations by differentLaw Enforcement Agencies (LEAs) on the same target are hidden from the3G intercepting control elements (ICEs). ICEs may be 3G MSC Server, 3GGMSC Server, P-CSCF, S-CSCF, SGSN, GGSN, HLR, AAA Server, PDG, MME,S-GW, PDN-GW, HSS.

The Administration Function and the Delivery Functions are each oneconnected to the LEMF via standardized handover interfaces HI1, HI2,HI3, and connected to a telecommunication system (GSN, which may be aSGSN or a GGSN) via the interfaces X1, X2, and X3. The ADMF is connectedvia the interfaces HI1 and X1 while DF2 is connected via HI2 and X2 andDF3 is connected via HI3 and X3.

The messages sent from LEMF to ADMF via HI1 and from the ADMF to the GSNvia the X1 interface comprise identities of a target that is to bemonitored. The DF2 receives Intercept Related Information (RI) from thenetwork via the X2 interface and delivers the IRI to relevant LawEnforcement Agencies through the HI2 interface. The Delivery FunctionDF3 receives Content of Communication CC, i.e., speech and data via theX3 interface and delivers the CC to the LEAs through the HI3 interface.

FIGS. 17-19 illustrate embodiments of lawful interception for MBBnetwork and CDN in accordance with embodiments of the invention.

FIG. 17 describes a embodiment for a method of implementing lawfulinterception. This embodiment is the easiest to implement and thereforeadvantageous. In this embodiment, if a UE has been targeted forinterception, then the UE is not assigned to a caching media server(e.g., MX-A 124). Therefore, all communications including OTT traffic toand from the UE can be intercepted at the GGSN 136 (and/or SGSN 135) andcommunicated to the LEMF as described above.

To implement this embodiment, DPI 137 may include additionalfunctionality to determine if a UE 110 is to be intercepted. The DPI 137checks the UE request and determines if the UE request belongs to a PDPcontext with LI flag set (e.g., UE is a LI target). If the UE is atarget, then DPI 137 will not forward the UE request to the CDN 180 forcontent deep packet inspection and assignment to a caching media server.Instead, the UE request is forwarded to the BG 160 or an on-path routerso that this request is processed without caching using the GGSN 136.

To determine if the UE is targeted, the DPI 137 checks with the GGSN 136for the PDP context using the source IP address as the index. Asdescribed above, GGSN 136 may interface with the LEMFs and may have theup to date information regarding the UEs being targeted. In someembodiments, only if the UE request matches the provisioned signatures,the DPI 137 checks with GGSN 136 for the LI information. This is becausethe DPI 137 forwards only those UE requests that match the provisionedsignatures (see FIG. 11).

DPI 137 and GGSN 136 may be a single unit or may be in separate units,for example, as described in FIG. 6. As described below, the location ofthe LI interception checking functionality may have architecturalramifications.

This information exchange is simpler if the GGSN 136 and DPI 137 areintegrated in a single unit because the PDP context data is readilyavailable and the mapping between UE's IP address and internationalmobile subscriber identity (IMSI) is easy as that data is also availablefrom the GGSN 136. This option is shown in FIG. 17 as option A.

Alternatively, at least two embodiments are possible if the DPI 137 is astandalone function independent of GGSN 136.

In a first embodiment, a proprietary API may be constructed to fetch thePDP data using UE IP as index from the GGSN 136. This may be structuredsimilar to the Gmc interface, which may either be a pull or a pushmodel. If the DPI 137 is integrated with DPI-C 181, then the existingGmc interface may be used.

In a second embodiment, DPI 136 may simply defer the checking to theDPI-C 181 and/or MC 182. The DPI-C 181 and/or MC 182 fetches themandatory updated LI information from the GGSN 136, for example, throughthe Gmc interface. This scenario is illustrated with the reference labelOption B in FIG. 17.

However, the embodiment described in FIG. 17 has some limitationsbecause of the location of the interception point which is the locationof the GGSN 136. Therefore, once a UE session is established through aMX-A 124, any updates to the LI flag has no impact on the ability tointercept the communication during that session. However, any new UEsession request can be monitored after the UE has been targeted. Inother words, UE's on-going session can not be monitored and only newsessions from this point on can be monitored. However, this limitationmay be acceptable under most LI regulations; for example, it isacceptable for North America.

FIGS. 18 and 19 describe embodiments of the invention for lawfulinterception that overcome these and other limitations.

FIG. 18, which includes FIGS. 18A and 18B, describes an alternativeembodiment for a method of lawful interception wherein the media serverin the layer2 network decides and delivers communications with atargeted UE, wherein FIG. 18A illustrates a context diagram ofimplementing LI and FIG. 18B illustrates the LI message flow.

Referring to FIG. 18A, two additional interfaces X1′ and X3′ arerequired for implementing this embodiment.

In this embodiment, the GGSN 136 is configured to notify the servingMX-A 124 of any updates to the LI requests from the LEAs. The MX-A IPaddress is regularly maintained in the PDP context as the requirement ofGmc interface. Therefore, the GGSN 136 notifies the serving MX-A 124 ofany new activation of LI for any UE, which is identified by UE IP. GGSN136 also notifies any deactivation of the LI target UE. Therefore, theMX-As store a table of list of all LI target UE's. In variousembodiments, the MX-A 124 is configured to have the ability to performinterrogation, which is described below. In particular, the MX-A 124 isconfigured to perform a mirrored delivery of any packet data to and fromthe UE's flagged as a target.

In various embodiments, the interfaces X1′ and X3′ may be implemented indifferent ways. In various embodiments, the interface X1′ may be used tocommunicate control messages from the GGSN, for example, after ADMFmakes a control decision. The interface X3′ may be used to communicatemedia data with the GGSN, for example, data during interception.

In one embodiment, GTP-U/GTP-C message tunnel between RNC 122 and GGSN126 may be implemented, for example, using the IWF 123.

In an alternative embodiment, the IP transmission that connects the MX-A124 and CDN 180 may be used. However, using the IP transmission, a VPNor IPSec has to be used for security reasons. Further, GGSN has to beconfigured to correctly identify that the packet data flow over the IPconnection from MX-A 124 is a valid UE traffic and forward to DF3.

The LI Message Flow for the LI framework described above with respect toFIG. 18A will now be described using FIG. 18B. The messages 1801, 1803,1805, 1806, and 1808 refer to messages that are compliant with 3GPPstandards (TS 3GPP 33.107). Messages 1802, 1804, and 1807 are addedherein in accordance with embodiments of the invention.

First, the target activation procedure will be described. The ADMF sendsTarget Activation 1801 (target ID, report type, etc.) to GGSN. The GGSNsets a flag for intercepted target in the PDP context. GGSN responds theresult to ADMF.

GGSN checks if the intercepted target has an activate PDP context. Ifthe target has an active PDP context, the GGSN notifies MX-A (target ID,GGSN IP, etc.) to monitor this target (message 1802). If this targetdoes not have an active PDP, the GGSN will wait until the next time thistarget establishes an active PDP context.

Next, the target deactivation procedure will be described. ADMF sendsTarget deactivation (target ID, etc.) to GGSN (message 1803). GGSNclears the flag for the intercepted target. GGSN responds to ADMFacknowledging the deactivation (message 1803). GGSN notifies MX-A(target ID, etc.) to clear its monitoring flag for this target (message1804). MX-A clears the flag for the UE being deactivated.

Target interrogation procedure will next be described. ADMF sends TargetInterrogation (target ID, etc.) to GGSN (message 1805). The GGSNresponds the result to the ADMF.

Intercepted communication content report procedure will next bedescribed. UE receives requested packet data from MX-A (message 1806).MX-A will also report a packet data (comprising target id, content ofthe data packet sent to the UE, GGSN IP, etc.) to the GGSN if this UE isflagged to be intercepted (message 1807). In various embodiments, theMX-A outputs a mirrored delivery stream towards the GGSN that matchesthe data being sent to the UE. The GGSN reports the intercepted packetdata (e.g., comprising target id, content, GGSN IP, etc.) from MX-A toDF3.

In an alternative embodiment, MX-A transmits interrogation (X3) directlyto the DF3 instead of using GGSN to relay the interrogated packet datastream. To implement this procedure, MX-A has to be configured totransmit interrogation with the following X3 message header information.The X3 message header comprises target identity; correlation number; anoptional time stamp; optionally a direction (indicating whether T-PDU ismobile originated (MO) or mobile terminated (MT)); and the targetlocation (if available).

However, these parameters are typically in the GGSN and therefore adirect connection to DF3 from MX-A may be less practical.

FIG. 19, which includes FIGS. 19A and 19B, describes a third embodimentfor a method of lawful interception wherein the media server in thelayer2 network decides and delivers communications with a targeted UEbut through the media controller, wherein FIG. 19A illustrates a contextdiagram of implementing LI and FIG. 19B illustrates the LI message flow.

Unlike the previous embodiment, in this embodiment, a media controllerMC interfaces between the MX-A and the GGSN. Referring to FIG. 19A,three additional interfaces X1″, X3′, and X3″ are required forimplementing this embodiment.

Referring to FIG. 19A, the MC 182 is the interface for the GGSN 136instead of the MX-A 124. The Gmc interface between the GGSN 136 and theMC 182 is utilized. Therefore, the MX-A 124 is notified from the MC 182not directly by the GGSN 136. This embodiment further simplifies theinteraction between the access networks and the CDN network. This isbecause the Gmc interface already provides the MC 182 with updated LInotifications (LI activation, deactivation etc. via the PDP contextupdate). Consequently, the X1′ interface for passing control informationregarding the LI activation, deactivation etc. is not needed. The X3′interface is the interrogation packet data flow between MC 182 and GGSN136 and is provided for the target LI UE. The X1″ interface between theMC 182 and the MX-A 124 may be used for transferring control informationregarding LI activation, deactivation etc.

The LI Message Flow for the LI framework described above with respect toFIG. 19A will now be described using FIG. 19B.

As described above, the ADMF may communicate to the GGSN regardingactivating a UE as a target (step 1901). The target activation iscommunicated to the MC (step 1902) through the Gmc interface, and to theMX-A through the X1″ interface (step 1903). Similarly, a targetdeactivation may be communicated to the GGSN (step 1904), which is thencommunicated to the MC (step 1905), and forwarded to the MX-A (step1906). Next, a target interrogation may be requested by the ADMF (step1907). The MX-A may initiate a packet data transmission with a UE thatis being targeted (step 1908). The MX-A generates a mirrored stream thatmatches the packet data communication with the UE. The MX-A transmitsthe mirrored packet data to the MC through the interface X3″ (step1909). The MC forwards the mirrored packet data to the GGSN (step 1910).The GGSN forwards the intercepted packet data received from the MC tothe DF3 (step 1911). In an alternative, the MX-A has a direct interfacewith DF3 avoiding going through the MC and GGSN (step 1912).

This embodiment advantageously allows lawful interception even duringroaming if the serving MX-A is changed to another MX-A (e.g., relocatesunder same SGSN). This is because MC is aware of this change andtherefore redirects the new serving MX-A to continue with the lawfulinterception. However, this embodiment may fail if the UE relocatesunder a new GGSN or if the MX-A fails.

In this embodiment, unlike the prior embodiment, the interface X3′between MC and GGSN is a media path and not a control path and may havesome limitations. Therefore, in some embodiments, the intercepted packetdata from MX-A may be directly sent to the GGSN as described in theprior embodiment.

In another alternative embodiment, the serving MX-A performs amid-stream redirect to the MX-B, which is deployed at the GGSN level, sothat all traffic will be monitored and sent to DF3 from GGSN. In variousembodiments, the UE does not detect any noticeable changes to thecurrent session although the serving media server is being moved up to amedia server situated at a higher level in the network. This may in turndepend on how the mid-stream redirection is done by the MX-A and thetypes of media and delivery protocol (assuming HTTP delivery of videocontent, the availability of the exact same content at MX-B, and the UEclient's support for mid-stream redirect), and the ability to start atMX-B at the point of redirect in the video.

It is important to note that these interrogation processes are veryresource intensive and security sensitive operations. Therefore, in someembodiments, it may be advantageous to combine the embodiments describedin FIGS. 17-19. For example, the embodiment of FIG. 17 may be used fornormal handling while the embodiment of FIG. 18 and/or FIG. 19 may beused in extreme situations. For example, LEAs may request that allsessions with a few selected target UE have to be intercepted. In suchrare situations, the embodiments described in FIGS. 18 and/or 19 may bedeployed. This will ensure optimizing the resource consumption withoutcompromising the ability to lawfully intercept communications.

FIG. 20 illustrates the handling of charging, reports, and analytics inaccordance with embodiments of the invention.

In various embodiments, charging and billing may include both post-paidand prepaid charging/billing support. The following diagram illustratesthe context for billing and some additional back office functions.

Embodiments of the invention include offline billing and real timecharging, which are described further below.

An embodiment of the invention relating to offline billing will be firstdescribed. A media data (MD) 186 in the CDN 180 collects usageinformation and reports to the Billing Center (BC) 191 after a certainnumber of pre-determined minutes (such as 10 minutes and it isconfigurable).

In accordance with an embodiment of the invention, a filtering algorithmmay be used. No control may be needed for subscribers on a flat rateplan (i.e. unlimited data plan). In contrast, for other subscribers,whose bills depend on the amount of data used, actual monitoring may bedependent on the type of subscriber plan.

Some subscribers may be allowed to use traffic even if they exceed theircontracted limits. However, such traffic called overage traffic isbilled differently. Embodiments of the invention enable hot billing forsubscribers with tiered traffic subscription packages. In accordancewith one or more embodiments, the MD 186 collects usage information fromall MX-A nodes and reports to BC 191 in every pre-defined number ofminutes. Thus, session for any user equipment that exceeds thepre-allocated limit or other limits may be terminated using hot billing.Hot billing requires continuous communication of user activity to the BC191. The overage of subscriber traffic usage is considered bearable forthis type of billing.

Alternatively, for subscribers without any contract (prepaid) or when anoperator may like to avoid the overage of traffic from thesesubscribers, real time charging may be required.

Therefore, embodiments of the invention relating to real time billingwill be described.

The GGSN 136 notifies the MC 182 via the Gmc interface that a new UE'sPDP includes an online charging gateway (OCG) flag indicating that realtime charging is needed for this particular UE. The MC 182 checks itslocal PDP info for OCG flag before redirecting this UE's request to aMX-A 124. In accordance with an embodiment of the invention, if the OCGflag indicates the need for real time charging, the MC 182 does notredirect the request to the MX-A 124. Instead, the MC 182 forwards therequest to the BG 160 or an on-path router so that this request will becharged in real time using the GGSN 136. Hence, under real time chargingno caching is performed.

Embodiments of the invention relating to reporting and analytics willnext be described.

The report generation for non-billing purposes such as NOC/operationalusage, network optimization, and tuning of DPI signature/algorithms canbe served from the MD 186. In various embodiments, the MD 186 may be acloud based Online Analytics Process (OLAP) that processes logs andoperational data from the CDN network.

In accordance with an embodiment of the invention additional data (MBBdata) may be collected because of the interaction between MBB networkand the CDN 180. Such additional data may include users' PDP contextdata, e.g., stored at MC 182, additional PCRF data (some of which isalready available from the Gmc interface), direct interface from PCRF133 to get additional QoS policy rules and parameters, and data from theAAA 231 and SUR 232 functions. Interfaces with AAA 231, SUR 232, PCRF133 may be added and supported at MD 186 to access these additionaldata. Embodiments of the invention also include interfaces between AAA231, SUR 232, PCRF 133 and MD 186. Using these additional data, andfurther processing, the network operation may be able to betterunderstand the OTT traffic (or B2B, B2C traffic etc.)

Embodiments of the invention relating to QoS approaches will bedescribed using the following methods and using FIG. 20.

QoS policy is an important consideration for communication networks.This is particularly so for mobile broadband networks than fixedbroadband networks. This is because the resources in the mobileinfrastructure is generally more limited and expensive compared with FBBnetwork infrastructure, for example the air interface and remotebackhaul. Also the revenue differentials from a VIP subscriber vs. a lowend subscriber can be 100× or more in MBB networks requiringdifferential treatment for these higher paying subscribers.

Referring to FIG. 20, in a first method, the MC 182 receives QoS/PCCparameters and uses it to provide differential treatment to users. Atthe MC 182, many QoS/PCC parameters may be passed on and routinelyupdated through the Gmc interface. For example, QoS/PCC parameters suchas charging based on user profile, charging based on service type,charging base on location, charging based on congestion, charging basedon time range, charging based on user's accumulate usage, charging basedon terminal type may be available at the MC 182. Further examplesinclude user service plan info such as VIP or premium user, userequipment types such as 3G capable device, user general location such asRAI and SAI, user roaming status such as roaming user, user group typesuch as corporate user vs. individual user, and user billing preferencetypes such as prepaid user.

The MC 182 may use the above information and allocate or select theappropriate media server (MX-A, MX-B, or MX-C) according to theseQoS/PCC parameters and the conditions of the MBB and CDN networks.

In one embodiment, the Quality of Experience (QoE) for the UE may beimproved by combining the request routing policy/heuristics with UEprofile and/or QoS parameters from PCRF 133 or the GGSN 136. Forexample, for VIP users, the PDP context data subset at the MC 182 mayindicate that the UE making the UE request has VIP status, and deservesspecial request routing treatment. For example, such VIP users may bealways routed to the serving MX-A with priority, for example, withfurther (implicit/explicit) instructions to serve UE with the highestbit rate (when multiple available) that matches the guaranteedthroughput in the PS/RAN link. Similarly, if a UE is not a VIP user,these requests may be forwarded to other media servers, e.g., MX-B 184or MX-C (at peering point/BG) or at service provider (SP) site toretrieve content and with lower throughput in the PS network to reserveresource for the VIP users. In alternative embodiments, a video rate maybe selected from a list of transcoded video rates. For example, the MC182 or media servers may have the option to transmit video at differentcoding rate. For example, depending on the UE profile, (e.g., thenetwork conditions) a file encoded at a higher video coding rate may beselected instead of transmitting a file encoded a lower coding rate. Forexample, a high resolution video may be selected for a user connectedthrough a high bandwidth connection while a low resolution video may beselected for a user connected through a low bandwidth connection.Further, in some embodiments, the video rate may be dynamically adjustedperiodically, e.g., every few seconds. For example, if the bandwidthdeteriorates during transmission, then the file with a lower coding rateis selected for the subsequent video segment. Similarly, a lowresolution video may be selected for a user device having a lowresolution screen (e.g., smart phone) while a large coding rate may beselected for a user device having a high resolution screen (1080p largescreen television).

In a second embodiment, the MC 182 directly retrieves information fromPCRF and uses this for serving UE over both MBB and FBB networks. Inthis embodiment, the MC 182, using a direct interface to the PCRF 133over Diameter (a AAA/Radius like interface) over IP, obtains policyrules from PCRF 133. This allows MC to obtain additional policy rulesthat may not be available from the private GGSN Gmc interface. Forexample, PCRF 133 may control both the MBB and FBB QoS policy rules, andtherefore, MC 182 may be able to obtain a common policy rules for aparticular user. Thus, in this embodiment, CDN 180 works directlybetween MBB and FBB with a common set of PCRF nodes.

In a third embodiment, the MC 182 forwards a subset of QoS data to theserving media server (e.g., MX-A 124), which then uses that informationto differentially serve the UE.

QoS policy parameters and rules may also be forwarded from the MC 182 toother functional components such as MX-A 124, MX-B 184, MX-C, MD 186(for analytics), and/or media storage cloud for B2B and B2C services.These components may react differently based on the forwarded QoSparameters and rules, the current conditions of the function/node, andother related environmental parameters to offer the appropriate QoS perUE type, etc.

One of the purposes of forwarding the QoS rules and parameters to themedia servers is that these media servers have the ability to adapt tothe changing requirements of any delivery at any time. For example,methods such as bitrate adaptation (with cached multi-ratesfiles/segments), on demand transrating at MX, or changing of media fileformat or characteristics (such as resolution, bitrates, mobile screendimension, media profile, etc.) may be performed on the fly to serve theUE with the most appropriate QoS demanded by policy entities such asPCRF 133.

Embodiments of the invention also include configuration of the mediaplayer and/or media server MX-A or MX-B etc so that the user may beserved more effective offering advanced features such as fast start,intelligent buffer control for smooth playback, HTTP rate capping,mid-stream redirect to another media server, recovery from a mediaserver failure, and/or collection and delivery of QoS data from themedia player to the CDN 180 for improving operation and accumulatingbusiness intelligence.

FIG. 21 illustrates the handling of failure of media servers inaccordance with embodiments of the invention.

As described in various embodiments above, each MX-A serves a largenumber of live subscribers. Therefore, failure of a MX-A can have acritical impact for many users unless mitigating procedures are inplace.

A first embodiment of failure recovery will be first described. Asillustrated in FIG. 21, IWF 123 is configured to immediately detect if aMX-A 124 fails or stops serving the UE 110 (see line 2201 in FIG. 21).

The IWF 123 either keeps a heart beat with MX-A 124 or sets a timerevery time IWF 123 forwards a message from UE 110 to MX-A 124. If MX-A124 does not respond after the heart beat timer or the message responsetimer expires, the IWF 124 is configured to forward this UE request (ora UE retry message) to the serving MC 182 on the PS path going throughDPI 137 and DPI-C 181 (line 2211 in FIG. 21). DPI 137 and DPI-C 181 areconfigured to forward this message to the MC 182, which also may have abroken heartbeat with the failed MX-A 124. The MC 182 selects adifferent media server such as MX-B 184, for example, which may likelybe the one connected to the GGSN 136/DPI 137/DPI-C 181, and redirect theUE request to the new media server MX-B 184. The UE 110 now continuesgetting media delivered from the MX-B 184 (line 2221 in FIG. 21).

The above described method requires enhancement at the IWF 123 and/orRNC 122 to detect failure of the MX-A 124 and to correctly route therequest to MC 182.

A second embodiment of the failure recovery method will be nextdescribed. This embodiment illustrates a simplification of the aboveembodiment in that the RNC 122 and/or IWF 123 are not modified. In thisembodiment, the MC 182 detects the failure of the MX-A 124, for example,because of a broken heart beat with MX-A 124. The MC 182 selects a newmedia server as described above, for example, MX-B 184 may be selected.The MC 182 constructs an HTTP direct message (HTTP 302) destined to eachof the currently impacted UEs while faking the source address as the IPaddress of MX-A 124. This is possible because the MC 182 convenientlyhas a list of the active PDP with IP addresses of UE's. The MC 182transmits these messages to the respective UEs. When each of thesemessage from MC 182 is received at the IWF 123/RNC 122, the IWF 123/RNC122 simply forwards them to the designated UE because the message comesin via the correct GTP-U tunnel and with the correct tunnel end pointidentifier (TEID). The UE's receiving such a message will contact thenew media server, e.g., MX-B 184, for delivery.

The first and the second embodiments described above may have somelimitations. For example, the user's media session may be abruptlyterminated and a new session may start from the beginning of the mediaclip when the new media server MX-B 184 starts streaming. In embodimentsusing HTTP adaptive streaming the media player may request the new feedfrom the point of failure of the previous session and therefore avoidthe user having to see the media clip from the beginning. However, thisissue may be difficult to avoid in the first and the second embodimentsof the invention using regular HTTP progressive download.

The following third embodiment is proposed to at least overcome theabove described limitations of the first and the second embodiments forfailure recovery. The third embodiment described below is an enhancementto the first and the second embodiments.

In accordance with this embodiment, the media player may be enhanced tohandle the transfer of the session from the first media server (MX-A124) to another media server (MX-B 184). When the media player at UE 110detects that it is being redirected to another media server in themiddle of a playback session (which means interruption of service), themedia player includes additional information regarding the session. Forexample, the media player may modify the HTTP Get request to the newmedia server (e.g. MX-B 184) with a BYTE RANGE request starting from thecurrent time code (TC) or byte range. For HTTP adaptive streaming,simply fetching the current segment (a few second worth of content) issufficient, and the rest will continue coming from the MX-B 184.

Embodiments of the invention also include methods for minimizingdegradation of user experience if even the backup media server (MX-B184) fails. For example, in accordance with an embodiment of theinvention, in case the backup media server MX-B 184 also fails, thefirst, second, and/or third embodiments described above may beimplemented. For example, the IWF 123 or the MC 182 may detect thefailure of the MX-B 184 and reallocate the UE request to a new mediaserver, for example, a MX-C connected to the BG 160 or core routers atpeering points of the operators' PDN. Alternatively, the MC 182 mayredirect to other MX-B's in the CDN 180.

Some of the network functions and components described above thatrequire re-configuration and provisioning are described below. Thefollowing discussion may not include all changes in configuration thatmay be required in implementing embodiments of the invention.

In one or more embodiments, interworking function and radio networkcontroller may need to be configured to recognize a local MX-A that theIWF may connect to, for example, based (such as an IP range). TheIWF/RNC may need to be configured to recognize failure of the localmedia server, for example, by the use of timers etc as described above.The IWF/RNC may need to be configured to recognize the IP address of themedia controller so as to be able to forward UE request when the localmedia server fails. The IWF/RNC may need to be configured with a mappingof IP address and Tunnel Endpoint Identifier (TEID) for the UE's beingserved. The IWF/RNC may need to be configured forward new RNC datapacket coming from IuR to IWF/MX-A, e.g., to enable continued streamingroaming/relocation or media failure.

In one or more embodiments, the GGSN may need to be configured torecognize IP addresses of the media controller. The GGSN may need to beconfigured to recognize MX-A IP addresses within the GGSN scope. TheGGSN may need to be configured to recognize DPI if the DPI queries theGGSN for PDP context information for decision making. The GGSN may needto be configured to send PDP context updates (creation, modification,and deletion) to the serving MC. The GGSN may need to be configured tomaintain the current serving MX-A for any given PDP context (UE).

In one or more embodiments, the SGSN may need to be configured tosuppress termination during/after relocation so that the old MX-A maycontinue to delivery the media stream to the UE. In some embodiments,SGSN is not changed unless we use it to pass on RNC IP or ID via GTPextension to pass that info to GGSN and placed in the PDP context fieldas a custom parameter.

In one or more embodiments, the local media server (MX-A) in the layer2access network may need to be configured with the GGSN IP address towhich it needs to connect for LI related features. MX-A may need to beconfigured with CDN default content retrieval algorithms and anydynamically provisioned updates to the MX-A from the CDN's networkoperations center. This configuration file may be used when there is acache miss in serving a UE request. MX-A may need to be configured tosend MX-A local logs to CDN's MD server(s), for example, for billing,charging, analytics. For lawful interception, MX-A may need to beconfigured to recognize the DF3 in case the method with directconnection to DF3 is used. In one ore more embodiments, MX-A may need tobe configured to receive PDP related info to support X3 interfacetowards DF3 such as target identity, correlation number, an optionaltime stamp, optionally a direction indicating whether transfer protocoldata unit (T-PDU) is mobile originated or mobile terminated, and thetarget location (if available).

In one or more embodiments, the media controller may need to beconfigured with the GGSNs IP addresses it is serving, each mediacontroller may serve multiple GGSNs. The media controller may need to beconfigured to recognize higher level media servers (MX-B) and DPI-Cfunctions and their IP addresses for forwarding messages. The mediacontroller may need to be configured with a table of the static mappingbetween RNC IP/ID and its local MX-A IP address. The media controllermay need to be configured to with PCRF's IP addresses.

In one or more embodiments, the media data function may need to beconfigured to recognize the Billing Server (BS) IP addresses and to beable to communicate with BS over a RESTful interface over IP. The mediadata function may need to be configured to recognize PCRF IP addresses,AAA server IP addresses, and SUR server IP addresses.

In one or more embodiments BS, PCRF, AAA, and SUR may need to beconfigured to recognize CDN components such as MD, and MC. In one ormore embodiments, DF3 used in lawful interception may need to beconfigured to recognize the MX-A IP addresses if the method of directMX-A to DF3 option is used.

Embodiments of the invention described above may be applied to othertypes of networks besides MBB networks.

In various embodiments, the MBB network may be 2G, 2.5G, 3G, 4G orhigher cellular wireless network. Embodiments of the invention may beapplied to other wireless networks such as WiMAX (or higher) networks.Similarly, embodiments of the invention may be applied to FBB networksincluding digital subscriber line (XDSL) networks, cable broadbandnetworks, fiber to the homes/premises (FTTX) networks, power linecommunication (PLC) networks, as examples. Wireless networks such asWiMAX and other fixed broadband networks or limited mobility networksmay have similar pressures resulting from the OTT traffic, which may bereduced using embodiments of the invention described above.

FIG. 22 illustrates a XDSL network implementing embodiments of theinvention described above. As illustrated in FIG. 22, a plurality of UEs2310 (e.g., UE-1, UE-2, UE-3) are serviced through an access network2320, which is coupled to a core network 2350 through a metro network2330. The access network 2320 comprises a digital subscriber line accessmultiplexer (DSLAM) 2321, which is a layer2 switch that connectsmultiple digital subscriber lines (DSLs) (UEs 2310) to a high-speedInternet backbone line using multiplexing techniques. The traffic fromthe DSLAM 2321 is switched to a Broadband Remote Access Server (BRAS)2322 from where the end user traffic is then routed across the ISPnetwork to the internet 2370. The BRAS 2322 is coupled through a servicerouter 2336, which may have the DPI 2337. Alternatively, the DPI 2337may be a separate unit in the metro network 2330. The DPI 2337 iscoupled to a core router 2361 in the core network 2350 and a DPI-C 2381in the CDN 2380.

In accordance with embodiments of the invention, a CDN 2380 having aDPI-C 2381 decides if a UE request involves a cacheable content and thena MC 2382 in the CDN 2380 assigns a media server to serve the UE 2310.The MC 2382 may assign a local media server such as MX-A 2324 in theaccess network 2320. In one embodiment, the MX-A 2324 is coupled throughan IWF 2323 as described in various embodiments so that MX-A 2324becomes the serving media server, and performs the caching functionsdescribed above in various embodiments. As described in variousembodiments above, the DPI-C 2481 may be integrated with the DPI 2337,MX-B 2384, and/or MC 2382.

FIG. 23 illustrates a cable broadband network implementing embodimentsof the invention described above. As illustrated in FIG. 23, a pluralityof UEs 2410 (e.g., UE-1, UE-2, UE-3) are serviced through a head-end2420, which is coupled to a core network 2450 through a metro network2430. The head-end 2420 comprises a quadrature amplitude modulation unit(QAM) 2421 that connects UEs 2410 to a high-speed internet backbone lineusing multiplexing techniques. The traffic from the QAM 2421 is switchedthrough a layer3 node 2422 from where the end user traffic is thenrouted across the ISP network to the internet 2470. The layer3 node 2422is coupled through a service router 2436, which may have the DPI 2437.Alternatively, the DPI 2437 may be a separate unit in the metro network2430. The DPI 2437 is coupled to a core router 2461 in the core network2450 and a DPI-C 2481 in the CDN 2480.

In accordance with embodiments of the invention, a CDN 2480 having aDPI-C 2481 decides if a UE request involves a cacheable content. Then aMC 2482 in the CDN 2480 assigns a media server to serve the UE 2410. TheMC 2482 may assign a local media server such as MX-A 2424 in thehead-end 2420. In cable broadband networks (e.g., used over CATVnetworks) the cable head-end may be a good location for MX-A 2424. Inone embodiment, the MX-A 2424 is coupled through an IWF 2423 asdescribed in various embodiments so that MX-A 2424 becomes the servingmedia server, and performs the caching functions described above invarious embodiments. As described in various embodiments above, theDPI-C 2481 may be integrated with the DPI 2437, MX-B 2484, and/or MC2482.

As described above, embodiments of the invention include PLC networks.In PLC networks, a local media server (MX-A) may be deployed in the lowvoltage or medium voltage head-end units for PLC network.

FIG. 24 illustrates a representative media device in accordance withembodiments of the invention.

The media device 2400 includes a receiver 2410, which may include awireless antenna receiver and/or a wired network connection port forreceiving the media content, for example, if it is stored at a remotelocation. The media device 2400 also includes a memory 2430, which mayinclude both a non-volatile memory and a volatile memory. In oneembodiment, instructions for performing the operations described withrespect to FIGS. 4-15, 17-23 may be stored in a non-transitory storagemedium such as a magnetic storage medium or a solid state storage mediumin the memory 2430.

The media device 2400 may include further I/O devices 2450 for inputtingand outputting data. For example, the I/O devices 2450 may include anoptical disc such as a laser readable medium, for example, a compactdisc reader, a blue ray disk reader, and/or digital video reader etc. Inone or more embodiments, the instructions for performing the operationsas described in FIGS. 4-15, 17-23 may be stored in an optical disc,which is a non-transitory storage medium.

The media device 2400 may also include a display 2460 and a transmitter2440 for transmitting the compressed data. The transmitter 2440 mayinclude plurality of wireless antennas and/or a wired port. Thetransmitter 2440 and the receiver 2410 can be combined together in someembodiments.

The media device 2400 includes a processor 2420 configured to executethe instructions for performing the operations described with respect toFIGS. 4-15, 17-23. The processor 2420 may comprise a single processor ora plurality of processors.

In various embodiments, the media device 2400 may be a L2 node such asradio network controller and/or eNB, IWF, L3 node such as a gatewayserver such as GGSN, SGSN, media server including MX-A, mediacontroller, media data function, DPI, DPI-C, PCRF, CG, DSLAM, BRAS, SRC,QAM, as well as other units described above in various embodiments (see,e.g., FIGS. 4, 7, 20, 22-23).

FIG. 25 illustrates components of a media controller for streaming mediain accordance with embodiments of the invention. The media controllermay include the general components described with respect to FIG. 24.Additionally, referring to FIG. 25, the media controller (e.g.,processor 2420 in FIG. 24) comprises a receiver 2510 configured toreceive a request to serve media content to a user equipment. A cachinginformation receiver 2520 is configured to receive caching informationregarding the media content. The caching information comprisesinformation regarding whether the media content requested by the userequipment is cacheable. The media controller 2500 further comprises anassignor 2530 configured to assign a first media server from ahierarchical set of media servers to serve the user equipment if themedia content to be served is cacheable. The hierarchical set of mediaservers comprises a plurality of first type of media servers deployed ina plurality of layer2 (L2) access networks. The user equipment iscoupled to a content delivery network through a layer2 access network ofthe plurality of layer2 access networks.

In one embodiment, the processor of the media controller comprises aplurality of separate chips performing one or more of the functions asthe receiver 2510, the caching information receiver 2520, and theassignor 2530. In an alternative embodiment, the functions of thereceiver 2510, the caching information receiver 2520, and the assignor2530 may be performed within the same processor at different times. Inother words, the processor behaves as the receiver 2510, the cachinginformation receiver 2520, and the assignor 2530 at various stages ofthe media processing.

FIG. 26 illustrates components of a media server 2600 for streamingmedia in accordance with embodiments of the invention. The media server2600 may include the general components described with respect to FIG.24. Additionally, referring to FIG. 26, the media server 2600 (e.g.,processor 2420 in FIG. 24) comprises a receiver 2610 configured toreceive a request to serve a cacheable media content to a userequipment. The user equipment is coupled to a content delivery networkthrough a layer2 (L2) access network. A determinator 2620 is configuredto determine if the cacheable media content is stored in a cache of thefirst media server. The media server 2600 does not determine if thecacheable media content is cacheable content. A server 2630 isconfigured to serve the cacheable media content from the cache to theuser equipment if the media content is stored in the cache of the firstmedia server.

In one embodiment, the processor of the media server 2600 comprises aplurality of separate chips performing one or more of the functions asthe receiver 2610, the determinator 2620, and the server 2630. In analternative embodiment, the functions of the receiver 2610, thedeterminator 2620, and the server 2630 may be performed within the sameprocessor at different times. In other words, the processor behaves asthe receiver 2610, the determinator 2620, and the server 2630 at variousstages of the media processing.

FIG. 27 illustrates components of a content processing unit 2700 forstreaming media in accordance with embodiments of the invention. Thecontent processing unit 2700 may include the general componentsdescribed with respect to FIG. 24. Additionally, referring to FIG. 27,the content processing unit 2700 (e.g., processor 2420 in FIG. 24)comprises a receiver 2710 configured to receive a request to serve mediacontent to a user equipment. The user equipment is coupled to a contentdelivery network through a layer2 access network of a plurality oflayer2 access networks. A determinator 2720 is configured to determinewhether the media content to be served is cacheable. A redirector 2730is configured to redirect the request to serve the media content to afirst media server if the media content to be served is cacheable. Thefirst media server is a media server from a hierarchical set of mediaservers. The hierarchical set of media servers comprising a plurality offirst type of media servers deployed in the plurality of layer2 accessnetworks.

In one embodiment, the processor of the content processing unit 2700comprises a plurality of separate chips performing one or more of thefunctions as the receiver 2710, the determinator 2720, and theredirector 2730. In an alternative embodiment, the functions of thereceiver 2710, the determinator 2720, and the redirector 2730 may beperformed within the same processor at different times. In other words,the processor behaves as the receiver 2710, the determinator 2720, andthe redirector 2730 at various stages of the media processing.

FIG. 28 illustrates components of an interworking function unit 2800 forstreaming media in accordance with embodiments of the invention. Theinterworking function unit 2800 may include the general componentsdescribed with respect to FIG. 24. Additionally, referring to FIG. 28,the interworking function unit 2800 comprises a receiver 2810 configuredto receive a request to serve a cacheable media content to a userequipment. A determinator 2820 is configured to determine a destinationIP address of the request. A forwarder 2830 is configured to forward thereceived request to a first media server in a first layer2 accessnetwork if the destination IP address matches a stored list ofdestination IP addresses. A repackager is 2840 configured to repackagethe received request into a TCP/IP message. The forwarder 2830 isconfigured to forward the received request to the first media server.

In one embodiment, the processor of the interworking function unit 2800comprises a plurality of separate chips performing one or more of thefunctions as the receiver 2810, the determinator 2820, the forwarder2840, and the repackager 2840. In an alternative embodiment, thefunctions of the receiver 2810, the determinator 2820, the forwarder2840, and the repackager 2840 may be performed within the same processorat different times. In other words, the processor behaves as thereceiver 2810, the determinator 2820, the forwarder 2840, and therepackager 2840 at various stages of the media processing.

FIG. 29 illustrates components of a second media server 2900 forstreaming media in accordance with embodiments of the invention. Thesecond media server 2900 comprises a receiver 2910 configured to receivea request to serve a cacheable media content to a user equipment. Therequest is received around when the user equipment is handed-off from afirst layer2 node in a first layer2 access network to a second layer2node in a second layer2 access network and a streaming session of thecacheable media content to the user equipment from a first media serveris terminated. The second media server 2900 further comprises adeterminator 2920 configured to determine if the cacheable media contentis stored in a cache of the apparatus, and a server 2930 configured toserve the cacheable media content from the cache to the user equipmentif the media content is stored in the cache of the apparatus. The secondmedia server 2900 may include the general components described withrespect to FIG. 24.

In one embodiment, the processor of the second media server 2900comprises a plurality of separate chips performing one or more of thefunctions as the receiver 2910, the determinator 2920, and the server2930. In an alternative embodiment, the functions of the receiver 2910,the determinator 2920, and the server 2930 may be performed within thesame processor at different times. In other words, the processor behavesas the receiver 2910, the determinator 2920, and the server 2930 atvarious stages of the media processing.

FIG. 30 illustrates components of a media controller 3000 for streamingmedia in accordance with embodiments of the invention. The mediacontroller 3000 may include the general components described withrespect to FIG. 24. The media controller 3000 comprises a receiver 3010configured to receive a second request to stream a cacheable mediacontent from a user equipment. The second request is received when theuser equipment is handed-off from a first layer2 node in a first layer2access network to a second layer2 node in a second layer2 access networkand a streaming session of the cacheable media content to the userequipment from a first media server is terminated. A assignor 3020 isconfigured to assign a second media server in the second layer2 accessnetwork to serve the user equipment.

In one embodiment, the processor of the media controller 3000 comprisesa plurality of separate chips performing one or more of the functions asthe receiver 3010, and the assignor 3020. In an alternative embodiment,the functions of the receiver 3010, and the assignor 3020 may beperformed within the same processor at different times. In other words,the processor behaves as the receiver 3010, and the assignor 3020 atvarious stages of the media processing.

FIG. 31 illustrates components of a layer3 node 3100 for streaming mediain accordance with embodiments of the invention. The layer3 node 3100may include the general components described with respect to FIG. 24.The layer3 node 3100 comprises a monitor 3110 configured to monitor if auser equipment is being handed-off. The layer3 node 3100 is configuredto terminate a session between a user equipment and a first media serverserving the user equipment. An identifier 3120 is configured to identifymedia content is being streamed from the first media server to the userequipment during an hand-off of the user equipment from a first layer2node to a second layer2 node. The layer3 node 3100 is configured toserve the first layer2 node and the second layer2 node. The layer3 node3100 is configured to not terminate the streaming of the media contentfrom the first media server if the user equipment is handed-off from thefirst layer2 node to the second layer2 node.

In one embodiment, the processor of the layer2 node 3100 comprises aplurality of separate chips performing one or more of the functions asthe monitor 3110, and the identifier 3120. In an alternative embodiment,the functions of the monitor 3110, and the identifier 3120 may beperformed within the same processor at different times. In other words,the processor behaves as the monitor 3110, and the identifier 3120 atvarious stages of the media processing.

FIG. 32 illustrates components of a media server 3200 for streamingmedia in accordance with embodiments of the invention. The media server3200 may include the general components described with respect to FIG.24. The media server 3200 comprises a server 3210 configured to serve auser equipment located in a service area of a first access network. Theserver 3210 is configured to serve the user equipment located in aservice area of a second access network after a hand-off of the userequipment from the first access network to the second access network.The serving comprises communicating with the user equipment through afirst layer2 node in the first access network, an interface between thefirst layer2 node and a second layer2 node in a second access network,and the second layer2 node to the user equipment.

In one embodiment, the processor of the media server 3200 comprises aplurality of separate chips performing one or more of the functions asthe server 3210. In an alternative embodiment, the functions of theserver 3210 may be performed within the same processor at differenttimes. In other words, the processor behaves as the server 3210 atvarious stages of the media processing.

FIG. 33 illustrates components of a deep packet inspection node 3300 inaccordance with embodiments of the invention. The deep packet inspectionnode 3300 may include the general components described with respect toFIG. 24. The deep packet inspection node 3300 comprises a receiver 3310configured to receive a request to serve media content to a userequipment, and a determinator 3320 configured to determine whether theuser equipment is a target for lawful interception. The determinator3320 is configured to determine the media content to be served is notcacheable if the user equipment is a target for lawful interception. Aforwarder 3330 is configured to forward the request to serve the mediacontent without caching if the user equipment is a target for lawfulinterception.

In one embodiment, the processor of the deep packet inspection node 3300comprises a plurality of separate chips performing one or more of thefunctions as the receiver 3310, the determinator 3320, and the forwarder3330. In an alternative embodiment, the functions of the receiver 3310,the determinator 3320, and the forwarder 3330 may be performed withinthe same processor at different times. In other words, the processorbehaves as the receiver 3310, the determinator 3320, and the forwarder3330 at various stages of the media processing.

FIG. 34 illustrates components of a media server 3400 in accordance withembodiments of the invention. The media server 3400 may include thegeneral components described with respect to FIG. 24. The media server3400 comprises a receiver 3410 configured to receive lawful interception(LI) information regarding a user equipment. The receiver 3410 isfurther configured to receive a request to serve a cacheable mediacontent to a user equipment. The user equipment is coupled through alayer2 access network. A determinator 3420 is configured to determinewhether the user equipment is a target for lawful interception based onthe received LI information. A server 3430 is configured to serve thecacheable media content to the user equipment. A generator 3440 isconfigured to generate a mirrored delivery stream for transmitting allcommunications with the user equipment to a law enforcement monitoringfacility if the user equipment is a target for lawful interception.

In one embodiment, the processor of the media server 3400 comprises aplurality of separate chips performing one or more of the functions asthe receiver 3410, the determinator 3420, the server 3430, and thegenerator 3440. In an alternative embodiment, the functions of thereceiver 3410, the determinator 3420, the server 3430, and the generator3440 may be performed within the same processor at different times. Inother words, the processor behaves as the receiver 3410, thedeterminator 3420, the server 3430, and the generator 3440 at variousstages of the media processing.

FIG. 35 illustrates components of a media server 3500 in accordance withembodiments of the invention. The media server 3500 may include thegeneral components described with respect to FIG. 24. The media server3500 comprises a receiver 3510 configured to receive lawful interception(LI) information regarding a user equipment from a layer3 node. Thereceiver 3510 is further configured to receive a request to serve acacheable media content to a user equipment. An assignor 3520 isconfigured to assign a first media server to serve the media content tothe user equipment. A transmitter 3530 is configured to transmit the LIinformation to the first media server. The receiver 3510 is furtherconfigured to receive a mirrored delivery stream of all communicationswith the user equipment if the user equipment is a target for lawfulinterception. The transmitter 3530 is further configured to transmit themirrored delivery stream to the layer3 node.

In one embodiment, the processor of the media server 3500 comprises aplurality of separate chips performing one or more of the functions asthe receiver 3510, the assignor 3520, and the transmitter 3530. In analternative embodiment, the functions of the receiver 3510, the assignor3520, and the transmitter 3530 may be performed within the sameprocessor at different times. In other words, the processor behaves asthe receiver 3510, the assignor 3520, and the transmitter 3530 atvarious stages of the media processing.

FIG. 36 illustrates components of a media controller 3600 in accordancewith embodiments of the invention. The media controller 3600 may includethe general components described with respect to FIG. 24. The mediacontroller 3600 comprises a receiver 3610 configured to receive userprofiles from a layer3 node in an access network. The user profilesinclude information relating to user account and/or networkcharacteristics of a user equipment. The receiver 3610 is configured toreceive a request to serve media content to the user equipment. Anassignor 3620 is configured to assign a first media server using an userequipment information from the user profiles. The assignor 3620 isconfigured to assign the first media server from a hierarchical set ofmedia servers to serve the user equipment if the media content to beserved is cacheable. The hierarchical set of media servers comprise aplurality of first type of media servers deployed in a plurality oflayer2 (L2) access networks. The user equipment is coupled to a contentdelivery network through a layer2 access network of the plurality oflayer2 access networks.

In one embodiment, the processor of the media controller 3600 comprisesa plurality of separate chips performing one or more of the functions asthe receiver 3610, and the assignor 3620. In an alternative embodiment,the functions of the receiver 3610, and the assignor 3620 may beperformed within the same processor at different times. In other words,the processor behaves as the receiver 3610 and the assignor 3620 atvarious stages of the media processing.

FIG. 37 illustrates components of a media server 3700 in accordance withembodiments of the invention. The media server 3700 may include thegeneral components described with respect to FIG. 24. The media server3700 comprises a receiver 3710 configured to receive user profiles froma media controller in a content delivery network. The user profilesinclude information relating to user account and/or networkcharacteristics of a user equipment. The receiver 3710 is furtherconfigured to receive a request to serve a cacheable media content tothe user equipment. The user equipment is coupled to the contentdelivery network through a layer2 access network. A determinator 3720 isconfigured to determine a quality of experience for the user equipmentby using an user equipment information from the user profiles. A server3730 is configured to serve the cacheable media content to the userequipment at the quality of experience for the user equipment.

In one embodiment, the processor of the media server 3700 comprises aplurality of separate chips performing one or more of the functions asthe receiver 3710, the determinator 3720, and the server 3730. In analternative embodiment, the functions of the receiver 3710, thedeterminator 3720, and the server 3730 may be performed within the sameprocessor at different times. In other words, the processor behaves asthe receiver 3710, the determinator 3720, and the server 3730 at variousstages of the media processing.

FIG. 38 illustrates components of a media data function 3800 inaccordance with embodiments of the invention. The media data function3800 may include the general components described with respect to FIG.24. The media data function 3800 comprises a receiver 3810 configured toreceive a delivery log of traffic use after every first time intervalfor an user equipment. The user equipment is part of a hot billing classof users. The traffic use comprises data usage by the user equipmentduring communication with a media server in a layer2 access network. Atransmitter 3820 is configured to transmit a user traffic informationfrom the delivery log to a billing and charging policy server. Thereceiver 3810 is further configured to receive account statusinformation from the billing and charging policy server. The accountstatus information is received if the user equipment exceeds a useraccount metric. The transmitter 3820 is further configured to transmitsession termination information based on the account status information.

In one embodiment, the processor of the media data function 3800comprises a plurality of separate chips performing one or more of thefunctions as the receiver 3810, and the transmitter 3820. In analternative embodiment, the functions of the receiver 3810, and thetransmitter 3820 may be performed within the same processor at differenttimes. In other words, the processor behaves as the receiver 3810, andthe transmitter 3820 at various stages of the media processing.

FIG. 39 illustrates components of a media server 3900 at a layer2 accessnetwork in accordance with embodiments of the invention. The mediaserver 3900 may include the general components described with respect toFIG. 24. The media server 3900 comprises a generator 3910 configured togenerate a delivery log comprising traffic use for an on-going sessionwith a user equipment. The generator 3910 is configured to generate thedelivery log periodically after every first time interval. A transmitter3920 is configured to transmit the delivery log periodically everysecond time interval. A receiver 3930 is configured to receive sessiontermination information. The session termination information is receivedif the user equipment exceeds a user account metric. A terminator 3940is configured to terminate the on-going session with the user equipment.

In one embodiment, the processor of the media server 3900 comprises aplurality of separate chips performing one or more of the functions asthe generator 3910, the transmitter 3920, the receiver 3930, and theterminator 3940. In an alternative embodiment, the functions of thegenerator 3910, the transmitter 3920, the receiver 3930, and theterminator 3940 may be performed within the same processor at differenttimes. In other words, the processor behaves as the generator 3910, thetransmitter 3920, the receiver 3930, and the terminator 3940 at variousstages of the media processing.

FIG. 40 illustrates components of a media controller 4000 in accordancewith embodiments of the invention. The media controller 4000 may includethe general components described with respect to FIG. 24. The mediacontroller 4000 comprises a receiver 4010 configured to receive arequest to serve media content to a user equipment. The receiver 4010 isconfigured to receive a subset of packet data protocol (PDP)information. The PDP comprises a flag indicating charging type of theuser equipment. A determinator 4020 is configured to determine thecharging type of the user equipment based on the flag. The determinator4020 is configured to determine the media content to be served is notcacheable if the charging type of the user equipment is a real timecharging type. A forwarder 4030 is configured to forward the request toserve the media content without caching if the charging type of the userequipment is a real time charging type.

In one embodiment, the processor of the media controller 4000 comprisesa plurality of separate chips performing one or more of the functions asthe receiver 4010, the determinator 4020, and the forwarder 4030. In analternative embodiment, the functions of the receiver 4010, thedeterminator 4020, and the forwarder 4030 may be performed within thesame processor at different times. In other words, the processor behavesas the receiver 4010, the determinator 4020, and the forwarder 4030 atvarious stages of the media processing.

FIG. 41 illustrates components of an inter working function unit 4100 inaccordance with embodiments of the invention. The inter working functionunit 4100 may include the general components described with respect toFIG. 24. The inter working function unit (IWF) 4100 comprises a firstdatabase 4110 configured to maintain a list of local media serversdeployed in a first layer2 access network, and a second database 4120configured to maintain a internet protocol (IP) address of a mediacontroller in a content delivery network. The media controller isconfigured to assign a media server to serve a user equipment. The interworking function unit 4100 further comprises a failure monitor 4130configured to determine if a local media server from the list of localmedia servers has failed, a receiver 4140, and a forwarder 4150. Thereceiver 4140 is configured to receive a request from the user equipmentto serve media content. The forwarder 4150 is configured to forward therequest from the user equipment to the media controller if the IWF 4100determines the local media server has failed.

In one embodiment, the processor of the inter working function unit 4100comprises a plurality of separate chips performing one or more of thefunctions as the first database 4110, the second database 4120, thefailure monitor 4130, the receiver 4140, and the forwarder 4150. In analternative embodiment, the functions of the first database 4110, thesecond database 4120, the failure monitor 4130, the receiver 4140, andthe forwarder 4150 may be performed within the same processor atdifferent times. In other words, the processor behaves as the firstdatabase 4110, the second database 4120, the failure monitor 4130, thereceiver 4140, and the forwarder 4150 at various stages of the mediaprocessing. Further, the first and the second databases 4110 and 4120may be stored in the memory 2430 of FIG. 24.

FIG. 42 illustrates components of a media controller 4200 in accordancewith embodiments of the invention. The media controller 4200 may includethe general components described with respect to FIG. 24. The mediacontroller 4200 comprises a assignor 4210 configured to assign a firstmedia server to serve a user equipment in response to a request to servea cacheable media content to the user equipment, and a failure monitor4220 configured to monitor a status of the first media server todetermine if the first media server fails. The media controller 4200further comprises a generator 4230 and a transmitter 4240. The generator4230 is configured to generate a redirect message having a sourcemessage of the first media server to the user equipment. The transmitter4240 is configured to transmit the redirect message. The assignor 4210assigns a second media server to serve the user equipment if the failuremonitor 4220 determines the first media server has failed. The generator4230 generates a redirect message if the failure monitor 4220 determinesthe first media server has failed. The redirect message redirects theuser equipment to the second media server. The transmitter 4240transmits the redirect message if the failure monitor 4220 determinesthat the first media server has failed.

In one embodiment, the processor of the media controller 4200 comprisesa plurality of separate chips performing one or more of the functions asthe assignor 4210, the failure monitor 4220, the generator 4230, and thetransmitter 4240. In an alternative embodiment, the functions of theassignor 4210, the failure monitor 4220, the generator 4230, and thetransmitter 4240 may be performed within the same processor at differenttimes. In other words, the processor behaves as the assignor 4210, thefailure monitor 4220, the generator 4230, and the transmitter 4240 atvarious stages of the media processing.

As described in detail above, various embodiments of the presentinvention have many advantages. First, embodiments of the inventionallow effective decoupling of the access network with the CDN networkfor OTT traffic caching. Second, embodiments of the invention enabledeployment of layer3 based media servers (media caching and adaptation)in a layer2 network, which is much closer to the end users without theusual complexity of layer2 DPI and decision making. Third, embodimentsof the invention support a more centralized content level DPI (DPI-C)and decision making in a single CDN, which may be able to serve both MBBand FBB networks. Consequently, DPI-C (content level deep packetinspection) functionality is not required within the access network.Fourth, embodiments of the invention may leverage a layered cachenetwork to increase cache hit rate and reduce cache miss retrieval time.Embodiments of the invention provide a hierarchy of caching media serverbackup among distributed media servers in case of failure of anyparticular media server. Fifth, embodiments of the invention, supportOTT, B2B and B2C services over MBB and FBB with a common, unified CDNwith identical network configurations, which greatly simplifies networkdeployment, management, and operations.

Although the present invention and its advantages have been described indetail, it should be understood that various changes, substitutions andalterations can be made herein without departing from the spirit andscope of the invention as defined by the appended claims. For example,many of the features and functions discussed above can be implemented insoftware, hardware, or firmware, or a combination thereof.

Moreover, the scope of the present application is not intended to belimited to the particular embodiments of the process, machine,manufacture, composition of matter, means, methods and steps describedin the specification. As one of ordinary skill in the art will readilyappreciate from the disclosure of the present invention, processes,machines, manufacture, compositions of matter, means, methods, or steps,presently existing or later to be developed, that perform substantiallythe same function or achieve substantially the same result as thecorresponding embodiments described herein may be utilized according tothe present invention. Accordingly, the appended claims are intended toinclude within their scope such processes, machines, manufacture,compositions of matter, means, methods, or steps.

What is claimed is:
 1. A method of serving media, the method comprising:receiving user profiles from a media controller in a content deliverynetwork, the user profiles including information relating to useraccount and/or network characteristics of a user equipment; receiving arequest to serve a cacheable media content to the user equipment, theuser equipment being coupled to the content delivery network through aaccess network; using an user equipment information from the userprofiles, determining a quality of experience for the user equipment;and serving the cacheable media content to the user equipment at thequality of experience for the user equipment.
 2. The method of claim 1,wherein the user profiles are received at a first media server deployedin a layer2 access network of the access network.
 3. The method of claim2, further comprising: determining if the cacheable media content isstored in a cache of the first media server, wherein the first mediaserver does not determine if the cacheable media content is cacheablecontent; and wherein the cacheable media content is served from thecache to the user equipment if the media content is stored in the cacheof the first media server.
 4. The method of claim 3, wherein serving thecacheable media content comprises selecting a bit rate that matches aguaranteed throughput of the access network.
 5. The method of claim 3,wherein serving the cacheable media content comprises selecting a videorate from a list of transcoded video rates.
 6. The method of claim 5,wherein selecting the video rate from the list of transcoded video ratescomprises dynamically adjusting the video rate according to changes innetwork conditions.
 7. The method of claim 1, further comprising servingthe cacheable media to the user equipment utilizing at least one of faststart, intelligent buffer control for smooth playback, hypertexttransfer protocol (HTTP) rate capping, mid-stream redirect to a newmedia server, recovery from a media server failure, and collection ofquality of service data from a media player.
 8. The method of claim 1,further comprising dynamically performing at least one of bitrateadaptation performing on demand transrating at MX, changing a media fileformat, changing a media file characteristic according to quality ofservice requirements.
 9. The method of claim 8, wherein the media filecharacteristics include at least one of resolution, bitrates, mobilescreen dimension, and media profile.
 10. The method of claim 1, furthercomprising selecting a coding rate for serving the cacheable mediacontent to the user equipment according to characteristics of the userequipment.
 11. A network component comprising: a processor; and anon-transitory computer readable storage medium storing programming forexecution by the processor, the programming including instructions for:receiving user profiles from a media controller in a content deliverynetwork, the user profiles including information relating to useraccount and/or network characteristics of a user equipment; receiving arequest to serve a cacheable media content to the user equipment, theuser equipment being coupled to the content delivery network through aaccess network; using an user equipment information from the userprofiles, determining a quality of experience for the user equipment;and serving the cacheable media content to the user equipment at thequality of experience for the user equipment.
 12. The network componentof claim 11, wherein the user profiles are received at a first mediaserver deployed in a layer2 access network of the access network. 13.The network component of claim 12, wherein the programming furtherincludes instructions for: determining if the cacheable media content isstored in a cache of the first media server, wherein the first mediaserver does not determine if the cacheable media content is cacheablecontent; and wherein the cacheable media content is served from thecache to the user equipment if the media content is stored in the cacheof the first media server.
 14. The network component of claim 13,wherein serving the cacheable media content comprises selecting a bitrate that matches a guaranteed throughput of the access network.
 15. Thenetwork component of claim 13, wherein serving the cacheable mediacontent comprises selecting a video rate from a list of transcoded videorates.
 16. A non-transitory computer-readable media storing computerinstructions for serving media, that when executed by one or moreprocessors, cause the one or more processors to perform the steps of:receiving user profiles from a media controller in a content deliverynetwork, the user profiles including information relating to useraccount and/or network characteristics of a user equipment; receiving arequest to serve a cacheable media content to the user equipment, theuser equipment being coupled to the content delivery network through aaccess network; using an user equipment information from the userprofiles, determining a quality of experience for the user equipment;and serving the cacheable media content to the user equipment at thequality of experience for the user equipment.
 17. The non-transitorycomputer-readable media of claim 16, wherein the user profiles arereceived at a first media server deployed in a layer2 access network ofthe access network.
 18. The non-transitory computer-readable media ofclaim 17, wherein the computer instructions for serving media furtherinclude computer instructions, that when executed by one or moreprocessors, cause the one or more processors to perform the steps of:determining if the cacheable media content is stored in a cache of thefirst media server, wherein the first media server does not determine ifthe cacheable media content is cacheable content; and wherein thecacheable media content is served from the cache to the user equipmentif the media content is stored in the cache of the first media server.19. The non-transitory computer-readable media of claim 18, whereinserving the cacheable media content comprises selecting a bit rate thatmatches a guaranteed throughput of the access network.
 20. Thenon-transitory computer-readable media of claim 16, wherein serving thecacheable media content comprises selecting a video rate from a list oftranscoded video rates.